Slow Solid State Drive
Slow Solid State Drive
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.
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.
Re: Slow Solid State Drive
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.
You need to dig into your addons to find out what is causing your level change speed issue.
Not a NFO employee
Re: Slow Solid State Drive
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.
Not a NFO employee
Re: Slow Solid State Drive
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.
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.
Re: Slow Solid State Drive
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.
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.
Not a NFO employee
Re: Slow Solid State Drive
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
Re: Slow Solid State Drive
That isn't very advanced, and a horribly inefficient way to do what you want.
Not a NFO employee
Re: Slow Solid State Drive
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 wrote:That isn't very advanced, and a horribly inefficient way to do what you want.
Re: Slow Solid State Drive
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.
I hope you understand the advanced concept of source engine string tables.
Not a NFO employee
Re: Slow Solid State Drive
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.
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.
Re: Slow Solid State Drive
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.stickz wrote: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.
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.I hope you understand the advanced programming concept of data recursion
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
- Former staff
- Posts: 1253
- Joined: Sat Nov 13, 2010 7:27 am
- Location: Dallas, TX
Re: Slow Solid State Drive
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
Re: Slow Solid State Drive
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.
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.
Re: Slow Solid State Drive
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.Vanderburg wrote: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
Re: Slow Solid State Drive
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.hakkuo23 wrote: 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.
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.