Beiträge von Chrzi

    Hab heut nochmal getestet, selbes Ergebnis. Ein Freund von mir erzielt um die 16s.


    Der request hat die Form wie vom Wiki vorgeschlagen

    Code
    {
       "action":"login",
       "param":{
          "apikey":"xxxxxxxxxxxx",
          "apipassword":"xxxx",
          "customernumber":"123456"
       }
    }

    Nachdem ich heute mal meine LetsEncrypt Zertifikate um Wildcards erweitern wollte, bin ich stän­dig in timeouts reingelaufen.


    Code
    #Exectued on a netcup server, ping and down-/upload speeds are normal
    time curl -H "Content-Type: application/json" --data "@test" "https://ccp.netcup.net/run/webservice/servers/endpoint.php?JSON"
    {"serverrequestid":"222DM2jojzy2VJIQn39U2RllGJM","clientrequestid":"","action":"login","status":"success","statuscode":2000,"shortmessage":"Login successful","longmessage":"Session has been created successful.","responsedata":{"apisessionid":"***************************"}}
    real    0m27.281s
    user    0m0.020s
    sys    0m0.004s


    Gehört das so? Gefühlt sind 27s für ein Login sehr hoch. Von meinem Rechner zuhause bekomm ich ähnliche Ergebnisse.

    Ich hab zwar bei mir nicht Bitbucket laufen, aber dafür GitLab, was ja recht ähnlich ist.
    Das ganze läuft auf einem RS 1000 G7, also 2 Cores und 6GB RAM. Wobei ich auch nur 1GB RAM abdrücke.


    Generell denke ich, dass du mit jeglichem Dual-Core Server gut fährst, solange du genug RAM frei hast.

    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 :/

    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.

    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.

    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...

    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?