Attempts to fix the lag
2007-07-29
The lag is long gone (and this page is released).
Embarassingly the lag had very little to do with all the technical kernel and library stuff. The lag was caused by increased traffic on the various server list and server status pages. The scripts that proved good at ru.setti.info were taking more and more CPU time, causing the mysterious lag on this more powerful CPU at pin.setti.info. Nowdays the dynamic pages are cached to reduce the required CPU time to render the pages.
2007-06-04
Kernels
- The original kernel of SuSE 10.1 (2.6.16.27-0.9)
- The same kernel version as the original patched to 1000 HZ (didn’t boot)
- 1000 HZ kernel version 2.6.21
- 1000 HZ kernel / hrtimers / real-time pre-emption
- 1000 HZ kernel / hrtimers / desktop-level pre-emption
- Tickless kernel / hrtimers / desktop-level pre-emption
- 300 HZ kernel / hrtimers / desktop-level pre-emption
New system libraries: libgcc_s.so, libstdc++.so, glibc
- The original system files of SuSE 10.1 (glibc 2.4, GCC 4.1.0)
- Files from official GCC 4.1.2 package
- Files from Crowfire.de (libgcc_s.so and libstdc++.so)
- Files from official GCC 3.3.6 package
- Files from official GCC 4.2.0 package
- Glibc 2.5
- Glibc 2.6
- Glibc 2.6 compiled with optimizations
Game servers
- The laggy version build 3048
- The first beta version build 3070
- The second beta version build 3090
- The third beta version build 3128
- General i686 optimized binaries
- General i486 optimized binaries
Miscellaneous tweaks
- Completely fresh install of game server without any modifications
- 24 player slots
- 20 player slots
- 18 player slots
- Game server prioritized over other programs
How to not to screw up the current system when testing the new libraries
Most of the libraries can be used without installing them system-wide. The srcds_run startup script contains line export LD_LIBRARY_PATH=”.:bin:$LD_LIBRARY_PATH”, which tells the system to prefer libraries in the main install directory “.” and in the game server “bin” directory. Just copying the libgcc_s.so and libstdc++.so files in “bin/” and restarting the server makes them active.
Glibc is so low-level system library that it needs special treatment. The library can be compiled and installed to custom directory by running the configure script with –prefix=/usr/local/glibc-2.6/ argument. Then compiling (make) and installing (make install) will not overwrite the current system libraries, which are needed practically by all processes on the machine. The new glibc can be activated for certain program by initiating the wanted program with /usr/local/glibc-2.6/ld-2.6.so. The ld-2.6.so is helper program, which decides where to look for the system libraries.
The srcds_run startup script uses many small system programs, which require additional system libraries. The script won’t find them, unless it is explicitly told where they are. That’s why the game server must be started directly with the approriate server binary, ie. srcds_amd. The other way around is to define LD_LIBRARY_PATH to contain the original library paths like /lib/, /usr/lib/, /usr/local/lib and such. Then the startup script will work using the original system libraries. The cavepit is that the server might launch itself using the original libraries too. Thus, the most simplified and certain way is to set LD_LIBRARY_PATH to “.:bin” and start the right srcds_* binary manually.So, the command line option to set library path correct and activate new glibc for CS:S server is the following:
export LD_LIBRARY_PATH=”.:bin”
/usr/local/glibc2/lib/ld-2.6.so ./srcds_amd -game cstrike +map de_dust2
The command above might fail to start with the following error:
./srcds_amd: error while loading shared libraries: ./srcds_amd: wrong ELF class: ELFCLASS32
In that case, there is program called linux32, which fakes the 64 bit environment to 32. Then the command line startup parameter is like this (assuming the linux32 program is located at /usr/local/bin/):
/usr/local/glibc2/lib/ld-2.6.so /usr/local/bin/linux32 ./srcds_amd -game cstrike
“linux32″ : http://www.novell.com/products/linuxpackages/enterpriseserver/x86-64/linux32.html
2 Comments
You must be logged in to post a comment.

Nowdays the dynamic pages are cached to reduce the required CPU time to render the pages.
Those pages were cached on ru.setti.info too. Caching times were too short and that caused lag which seemed to come at irregular intervals. Caching time which was relevant to the lag was 10 minutes - for those neat pie graphs on server stats - but due to large amount of servers there was constantly someone reloading a page which was not cached. That was not that much of an issue on ru.setti.info.
Comment :: July 29, 2007 @ 9:27 pm
[…] After having the rescuesystem at hand, it should be easy task to revert the change in the Linux’s boot loader (LILO) and run the boot loader command again to write the old boot sector back to the disk. This is how it worked on the previous server. You didn’t even notice when the kernel was updated many times. Unfortunately the easy part stopped to the “reverting the change” part. Executing the changes back to the disk was whole another matter. […]
Pingback :: December 10, 2007 @ 7:59 pm