• Please make sure you are familiar with the forum rules. You can find them here: https://forums.tripwireinteractive.com/index.php?threads/forum-rules.2334636/

Server Workshop map disk thrashing is back!

WorthlessJ

Member
Mar 25, 2020
5
0
As the title states, servers are back to ABSOLUTELY DESTROYING Disk IO when using workshop maps due to checking and logging map versions. I'll provide picture and some hopefully helpful information below. If anyone has a workaround in the meantime, other than using FastDL instead, I would love to hear it!
foook.jpg
OS:
Ubuntu Linux 18.04

KF2 Server Version:
Live

Sidenote: Really dissapointed because I spent a good chunk of time moving 6 servers off FastDL and onto Workshop, not looking forward to setting fastdl back up.
 
Out of curiosity, are you using the same set of files, but with the same "configSubDir" or different set of files for each game server? If you are using separate set of files then you do not need to use the "configSubDir" parameter, especially as it messes up config files between updates where new content gets updated as far as I know, you have to manually add new maps/gamemodes/whatever is new in config files manually. Also I find it weird you're using the QueryPort parameter but you do not set the game Port. Unrelated to your issue but everything looks odd to me here.
 
Upvote 0
So you're saying the servers check on startup and on map change, that would very quickly explain the problem. I was under the assumption from previous posts that the servers only check on startup, which I can plan around. I have 92 workshop files (maps) on 6 different server instances. So worst case scenario I can have 552 checks going at once, and basically smash my hdd because it's checking all day with 6 populated servers changing maps often. Am I understanding your post correctly? Cheers.

This would also explain why I noticed the HDD IO was much more random instead of the constant hard hitting that used to exist for workshop files.

Edit: Romano, I am not using configSubDir, and the command line looks weird because I have most of the configurable settings set in the .ini files. How would anyone connect if the port was the same on every server? :) cheers
 
Upvote 0
That would be really surprising that an issue reported since one or two years, supposedly fixed in an update would actually still be a thing in the next :unsure:.. Honestly I stopped my server, always the same boring story with TWI these past years. I lost faith, and for good reasons, but let see, maybe I'm wrong and the guy doesn't have issues. I'm not starting my server because I think it would be the final blow for me to go definitely nuts, if that would be the case.
 
Upvote 0
So you're saying the servers check on startup and on map change, that would very quickly explain the problem. I was under the assumption from previous posts that the servers only check on startup, which I can plan around. I have 92 workshop files (maps) on 6 different server instances. So worst case scenario I can have 552 checks going at once, and basically smash my hdd because it's checking all day with 6 populated servers changing maps often. Am I understanding your post correctly? Cheers.

This would also explain why I noticed the HDD IO was much more random instead of the constant hard hitting that used to exist for workshop files.

Edit: Romano, I am not using configSubDir, and the command line looks weird because I have most of the configurable settings set in the .ini files. How would anyone connect if the port was the same on every server? :) cheers
It does two checks at start up and in between maps. This started with the issue with workshop content not being updated at all, we fixed that but made the amount of checks too aggressive, we reduced the isolated it to specific points in the server runtime to mitigate the issue.
 
Upvote 0
From your screenshot you're definitely using ConfigSubDir parameter, with a "kf2server" config sub dir, hence the question, are you using one set of files or multiple set with this parameter.

edit;: also the problem with TWI is that even after asking for information about how the system was supposed to work, what they changed to 'fix' the issue, how it is supposed to work after the fix, and so on, it is mystical information, never had detailed information.
 
Last edited:
Upvote 0
It does two checks at start up and in between maps. This started with the issue with workshop content not being updated at all, we fixed that but made the amount of checks too aggressive, we reduced the isolated it to specific points in the server runtime to mitigate the issue.
Maybe it is time to consider extreme cases where people have 50 to hundreds of workshop items, and acknowledge the server admins request (personnally I don't care I never suffered from these insane I/O problems) about a setting to decide the frequency of the workshop checks (like a setting to only check on server start, a setting to only check every XX hours or days, and so on..) or even the ability to disable workshop checks completely if you guys at tripwire can't make a system where it only checks the appworkshop_232090.acf file instead of doing these insane disk reads, the actual system is non sense to me why would it even read the workshop map files when it literally just needs to check for the info contained in this appworkshop_232090.acf file and compare it with the workshop info. Really, this is non sense to me. If we can have insight from the qualified TWI staff about the system to explain why it is so bad that would be great, because it's been years that I see people complaining about how workshop for server is degrading server performance (when not simply destroying hardware).
 
Upvote 0