Slow Solid State Drive

[stickz]

My sever identifier is xenogm001.

I would like to complain the solid state drive on this dedicated machine is too slow. I have experienced faster level change speeds on VDSs which have solid state caches. The disk is a huge bottleneck for gameservers (specially that one) which takes longer than it should to change level. Is this a configuration issue, a lack of i/o (you don't offer stripes) or both?

I fully understand the concept of third-party features (such as addons) putting more strain on the disk.

[soja]

The level change speeds are probably not I/O bound. My servers load 200-300MB BSPs along with addons and a 100MB sourcemod clientprefs database and the map changes are instant on both magnetic and solid state storage.

You need to dig into your addons to find out what is causing your level change speed issue.

[soja]

When you rented your managed dedi, did you specify you wanted to use the SSD? If not, you are on the HDD on your dedi, even if it has both drives installed.

[stickz]

soja, I am waiting for a response from Edge. These comments aren't very productive or useful to myself. I understand the concept of hardware and code which uses it.

Edit: I have achieved near instant changes on other gameservers, but don't have full access to managed configurations which is an acceptable trade-off for features.

[soja]

Sure they are productive. My first post lets you know that in my experience(currently 6 managed dedis, using both SSD and HDD) especially for source based game servers the required disk I/O is very low. Any extended map change times are the result of a plugin/addon misconfiguration. I told you where to look for issues.

In my second post, if you didn't specify during the installation process to use the SSD, you are on the HDD. I was trying to gather information to be able to better advise you.

If you don't want community comments on your problems, stick to tickets.

[stickz]

Alright, this is likely why it takes so long. I hope you understand the advanced programming concept of data recursion, I need more for i/o for this.

Code: Select all

/* Running this function is VERY laggy and takes a LOT of time to run
   However it saves us time from manually doing all the files, one at a time */
   
--check an table to MASSIVELY speed up the process 
fileTypes = {
	"vmt",
	"vtf",
	"mdl",
	"wav",
	"png",
	"pcf",
	"mp3",
	"ttf",
	"txt"
} 
   
local function ProcessFolder ( Location )
	local files, directories = file.Find(Location .. '*',"GAME")
	for k, v in pairs(files) do
		if file.IsDir(Location .. v,"GAME") then
			ProcessFolder(Location .. v .. '/')
		else
			local OurLocation = string.gsub(Location .. v, 'gamemodes/' .. FOLDER_NAME .. '/content/', '')	
			if table.KeyFromValue(fileTypes,string.sub(OurLocation, -3)) then	
				resource.AddFile(OurLocation)
				if false then
					MsgN("resource.AddFile(\""..OurLocation.."\")") -- for dumping to console
				end
			end
		end
	end
	for k, v in pairs(directories) do
		if file.IsDir(Location .. v,"GAME") then
			ProcessFolder(Location .. v .. '/')
		else
			local OurLocation = string.gsub(Location .. v, 'gamemodes/' .. FOLDER_NAME .. '/content/', '')
			if table.KeyFromValue(fileTypes,string.sub(OurLocation, -3)	) then			
				resource.AddFile(OurLocation)
				if false then
					MsgN("resource.AddFile(\""..OurLocation.."\")") -- for dumping to console
				end
			end
		end
	end
end



if !ResourcesProcessed then 
	ProcessFolder('gamemodes/' .. FOLDER_NAME .. '/content/models/')
	ProcessFolder('gamemodes/' .. FOLDER_NAME .. '/content/materials/')
	ProcessFolder('gamemodes/' .. FOLDER_NAME .. '/content/resource/')
	ProcessFolder('gamemodes/' .. FOLDER_NAME .. '/content/sound/')
	ProcessFolder('gamemodes/' .. FOLDER_NAME .. '/content/scripts/')
	ResourcesProcessed = true
end

[soja]

That isn't very advanced, and a horribly inefficient way to do what you want.

[stickz]

That isn't very advanced, and a horribly inefficient way to do what you want.

I could just put the resource.AddFile 400 times; then, forget to add a few of the files and constantly mess up links when adding new things. It's a tradeoff, but well worth it.

[soja]

I would suggest running the script once to add all files to the downloads table, then dump the table and use notepad++ expressions to create a lua file that has all of your resource files clients need to download. That way you don't run that horribly slow script each map load.

I hope you understand the advanced concept of source engine string tables.

[stickz]

It's not a concern if the server takes five seconds to change level. I'd rather see if there's an easier way out honestly.

Everything will be using pcie ssds in the future instead of the slower sata interface , i'm just a little bit ahead of the game with scripts.

[hakkuo23]

It's not a concern if the server takes five seconds to change level. I'd rather see if there's an easier way out honestly.

Everything will be using pcie ssds in the future instead of the slower sata interface , i'm just a little bit ahead of the game with scripts.

Better hardware should NOT be used to utilize bad coding practices. It's meant to hold more of a load on it. Trying to justify a bad script is just awful and you should feel bad.

I hope you understand the advanced programming concept of data recursion

Your purpose may require recursion, but it looks like you would be better off making a list of all files that need to be precached, or at the very least, modifying your script as Soja said. The way you are doing is extremely stupid and unfair to the rest of the servers on the box. It increases the cost of servers you need.

The method you are doing will also just send EVERYTHING to the client, including stuff that shouldn't be sent, and that's just silly.

A resource list should really be static, and there are plenty of services to do this: I found one just googling for 5 seconds:
https://www.facepunch.com/showthread.php?t=842886

The source is there, repurpose it to your liking and implement the "advanced programming concept of data recursion" to your liking.

[Vanderburg]

I've also written a script that will do this. It scans the webhosting you're using for the fastDL files directly, and will grab Workshop addons from a collection ID. You can then just click "Download" and it'll send you the file to upload to your game server. Makes it pretty painless to run each time you make a change. You can find it here: http://www.configcreator.com/create/gmod/resources.lua

[stickz]

Getting the average reloading speed down to 15-20s for my clients and slashing the initial retrieving game data time is very tempting.

I may actually end up implementing a resource file after-all as it benefits more than just the server hardware.

I kinda feel bad for those other server operators using an older version this script with (9 x 2 string subs) on those slower vds drives.

[stickz]

I've also written a script that will do this. It scans the webhosting you're using for the fastDL files directly, and will grab Workshop addons from a collection ID. You can then just click "Download" and it'll send you the file to upload to your game server. Makes it pretty painless to run each time you make a change. You can find it here: http://www.configcreator.com/create/gmod/resources.lua

I don't use workshop files on my gmod server expect for the gamemode lua files and a 3.8mb content pack with 198 files. The effect on loading times are tremendous (atleast on my client stripe) and workshop is notorious for having stupidly slow download speeds. If that happens out of Chicago, I just ring up a support request and get the transit changed. It may take the clients latency x 400 files to download, but it's almost flawless; and, afterwards there's no negative effects.

[stickz]

https://www.facepunch.com/showthread.php?t=842886
The source is there, repurpose it to your liking and implement the "advanced programming concept of data recursion" to your liking.

well, whatever is faster. I forgot to mention, I got this working in like an hour. It was as simple as creating a .substring(1) on visual studio to chop off the first string index, recompiling then the syntax was correct. Level change speeds have been much faster and more consistent since then.

There's still a few flaws where my client stripe takes 20s to load. I wish it could meet my standards and consistently take 8-10s; but, at-least the stupid loading times are gone now. I think that is related to optimization on a map level though. The map-level factors are unknown to myself though, as size doesn't seem to be the determining factor but there does seem to be a linear relationship in-terms of probability; similar to the concept of latency.