Schlechte CS:GO Server Performance

    Auf meinem Root Server L v6 läuft Nginx, MySQL und ein Minecraft-Server anstandslos, nur der CS:GO Server will nicht recht.


    Zur Problematik:
    Die CPU-Auslastung auf einem Kern ist sehr hoch 90-100%, wodurch der Server immer wieder Framedrops hat und nicht hinterherkommt. Choke (Datenverlust vom Server zum Client) im Bereich von 5-30% sind die Regel, auch die sv Variable springt freudig von 5ms auf 30ms hoch.
    Sonst scheint Arbeitsspeicher mit 2-3GB noch frei und I/O Perfomance mit den SSDs okay zu sein, das Netzwerk sollt auch nicht hinterherhinken.


    Die Servereinstellungen sind 128 Tick und max. 10 Spieler (normales Competitve).


    Da ein Freund den gleichen Server hier bei netcup hat und es bei ihm unter Debian ohne Probleme läuft, hab ich mal kurz neben Ubuntu ein frisches Debian Jessie installiert, mit dem gleichem Problem...


    Hat jemand eine Idee woran das liegen könnte und warum es auf einem (fast) gleichen Server läuft?

    Schneid mal bitte ein paar Sekunden lang "vmstat 1" mit wenn es langsam ist. Außerdem bitte mal mit top sehen welcher Prozess/Thread das genau ist.


    Danach könnten wir den Prozess ja mal mit strace quälen. Wobei das könntest auch gleich machen, bitte ein paar Sekunden strace vom schuldigen Prozess/Thread.
    Ich denke das sollte erstmal etwas Licht ins Dunkle bringen.


    Bin gespannt...


    Thomas


    PS: CS:GO ist ein Counterstrile-Gameserver, korrekt?

    Danke für die schnelle Antwort :)


    Zuerstmal ja bei CS:GO handelt es sich um Counterstrike: Global Offensive.


    OS ist übrigens Ubuntu 14.04 mit 4.4.0-34-generic Kernel


    Der vmstat ist im Anhang, denn ich glaub der strace ist interresanter :D
    Insgesamt waren das 15-20 Sekunden und 200.000+ Log-Nachrichten.
    Den Log hab ich mal etwas gekürzt, die Parameter variieren etwas wie man trotzdem gut sehen kann.


    Scheint so als ob er sehr an der aktuellen Zeit interessiert wäre...

    Okay, also einen Schritt weiter.
    Der accept mit 'EAGAIN' ist kein Fehler. Es liegen keine Daten auf dem Socket vor (und der Socket ist non-blocking).


    Das viele Abfragen von gettimeofday(), teilweise nach 50 oder weniger Mikrosekunden finde ich schon sehr krude.
    Schwer zu sagen ob das normal ist, es sieht jedenfalls nicht normal aus.
    Soetwas könnte man z.B. machen wenn man präzise irgendwas messen muss.


    Hast du mal geschaut welcher Thread das ist? htop zeigt ind er Standardeinstellung Threads an.
    Vom vmstat sieht es so aus als würde ein Core im UserMode im Kreis rennen.
    Das heißt zwischen den Aufrufen von gettimeofday() ist wohl noch viel im Kreis gespringe dazwischen was die CPU zum brennen bringt.


    Interessant wäre auch ein Pstack - kannst du das ein paar mal auf den Prozess ausführen der soviel CPU braucht?
    Außerdem würde ich gerne den Server runterladen damit ich mir den Assembler-Code zum pstack ansehen kann.
    Ich denke da werden keine Debug-Informationen gelinkt sein :(


    Thomas

    Soweit ich das beurteilen kann ist das der Hauptthread vom Server:

    [Blockierte Grafik: https://upload.die-bruderschaft.org/images/cshtop.png]


    pstack gibt leider nur "only 64 bit objects supported." aus, der Server ist in 32 bit.


    Runtergeladen und installiert kann er nur werden über Steam, dafür gibt es aber auch ein kleines Tool, falls man sich nicht mit dem SteamCMD herumärgern möchte.
    Mit dem Linux Game Server Manager (auch empfohlen von den Entwickerln des Spiels, Valve) csgoserver: Counter-Strike: Global Offensive | Linux Game Server Managers hab ich ihn installiert.

    Ja, scheint als wäres der Hauptthread.


    Wenn pstack nicht geht, nimm einfach mal gdb und mach "thread apply all bt".
    Achtung: Während du mit gdb im Programm hängst steht es.


    Ich nutze dazu folgenden Befehl, dann hängt es nur kurz:

    Code
    gdb <<GDBEND > ~/stackdump.txt
attach 16001
info threads
thread apply all bt
detach
quit
GDBEND


    (für 16001 musste natürlich die richtige pid einsetzen)


    Von den Backtraces ein paar machen ubd mit dazu schreiben welcher Thread (id) gerade viel cpu brät.
    Vielleicht finden wir was.


    Thomad

    Der einzige Thread der viel CPU braucht ist der Hauptthread 19698 mit 70-100% laut htop.
    Ansonsten verbrauchen noch 2 Minecraft-Server Threads jeweils rund 30%.


    gdb hat funktioniert, allerdings diesen Fehler hier ausgespuckt:

    Code
    Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x3:
Cannot access memory at address 0x3


    Die Backtraces sind im Anhang.

    Also im ersten Backtrace finden wir garnichts sinnvolles:

    Code
    * 1	Thread 0xf74c2700 (LWP 19698) "srcds_linux" 0xf76e8cd9 in ?? ()


    Die anderen beiden scheinen zumindest Funktionsnamen zu beinhalten:

    Code
    * 1	Thread 0xf74c2700 (LWP 19698) "srcds_linux" 0xf2c59713 in ConcatTransforms(matrix3x4_t const&, matrix3x4_t const&, matrix3x4_t&) () from /home/csgo/gsm/serverfiles/csgo/bin/server.so* 1	Thread 0xf74c2700 (LWP 19698) "srcds_linux" 0xf5fcdea3 in CM_LeafOcclusionPass(COcclusionInfo&, int, float, float) () from /home/csgo/gsm/serverfiles/bin/engine.so


    Leider wirds natürlich jetzt hier schwierig ohne den Programmcode, das Binary oder zumindest einen aussagekräftigen Funktionsnamen zu sehen was genau da passiert.
    Du kannst ja mal schauen ob du bei noch ein paar Backtraces einen bestimmten Funktionsnamen oft siehst - dann deutet das daraufhin dass zumindest diese Funktion was damit zu tun hat.


    Ich denke dass der Server irgendwas zu oft macht. Ein Problem mit dem Hostsystem würde ich ausschließen.
    Du kannst ja mal schnell einen

    Code
    sysbench --num-threads=1 --test=cpu --cpu-max-prime=20000 run


    testen. Aber solange der Prozessor da um die 30 Sekunden braucht ist das absolut normal.
    Der Wert sollte ähnlich sein wie der deines Freundes der die Probleme nicht hat.


    Damit schließen wir zumindest aus dass CS soviel Prozessorlast zieht weil der Prozessor so langsam ist.
    Aber das hatte ich eigentlich von vornherein nicht vermutet...


    Wie man dann hier weiterkommen soll ist schwierig. Eventuell, da es ja kein OpenSource Programm ist, mal einen Support-Case erzeugen?


    Thomas



    Da er beim sysbench 32 Sekunden gebraucht hat scheint das okay, somit ist wohl der Support-Case das Mittel der Wahl.
    Falls dort eine Lösung bei rumkommt, werde ich die hier posten.


    Vielen Danke ThomasChr für die umfangreiche und schnelle Hilfe! Auch wenn es letztendlich nicht viel gebracht hat :/

    Wenn du Lust hast könntest du das erstellen von dem Backtrace nich scripten. Mach einfach nur mal "bt", das sollte dann nur den ersten Treffen, und dann mal ein paar hundert Backtraces. Danach ein "cat DATEI | sort | uniq -c | sort -n" sollte dir die Funktion liefern wo er häufig angetroffen wurde. Außerdem sehen wir die anderen Funktionen auch. Vielleicht ergibt sich ein Muster.


    Auch wenn du das nicht mehr versuchen willst, Berichte mal wenn es gelöst ist.
    Bin gespannt was es ist. Jedenfalls hats -imho- nix mit der Hardware, der Virtualisierung und wahrscheinlich auch nichts mit dem Betriebssystem zu tun. Da bin ich mir eigentlich relativ sicher, weils ja klar ein User-Mode-CPU Spin ist.


    Thomas

    Hey, hab leider bermerkt dass ich auf meinem Root L das gleiche Problem habe... Interessant dabei ist jedoch das bei einem Game mit 9 Bots die SV Rate in den Keller geht, aber bei nem sysbench Test auf 4 Threads alles noch halbwegs normal läuft.


    EDIT: Ich werde es nun mal auf einem vServer 4000 G7 versuchen und hier ggf. ergänzen.
    EDIT2: Der Fehler tritt nicht ganz so stark auf, jedoch geht der Server wie bereits beim Root in die Knife ab und an.