RAM Limit ausgeschöpft?

    Auf einem vServer 2000 läuft Debian Lenny 64Bit mit zwei Counter-Strike: Source Servern (12 Slots +2 Reserve) und Apache 2.2.9 (HTML für MOTD-Page und Fast-Download).


    In letzter Zeit waren die beiden CS: S-Server mehrmals nach einiger Zeit nicht mehr zu erreichen, woraufhin der vServer über das netcup VServer Control Panel neu gestartet wurde und anschließend wieder fehlerfrei lief.


    Beim Auftreten dieses Problems steht im netcup VServer Control Panel die Fehlermeldung:

    Zitat

    Seit dem letzten Start hat Ihr VServer mindestens einmal sein RAM Limit ausgeschöpft.

    Die Arbeitsspeicherauslastung habe ich bereits während und nach diesem Fehler überprüft, wobei sich die Auslastung nicht wesentlich unterschied.
    free -m

    Code
    total  	used   	free 	shared	buffers	cached
Mem:      	2048   	2048  	0      	0      	0   	1965
-/+ buffers/cache:     	82   	1965
Swap:     	2048  	0   	2048


    Soweit ich das nachvollziehen kann, werden in diesem Fall ca. 82 MB durch Prozesse beansprucht, während die Festplatte ca. 1965 MB zum schnelleren Zugriff im Arbeitsspeicher auslagert. Diesen Speicher können Prozesse aber beliebig überschreiben und Swap wird nicht verwendet.


    Die Cache-Funktion wurde mit einem Kernelupdate im April 2010 von netcup eingeführt. Ein Problem damit meldete im letzten Jahr bereits ein anderer Kunde. Ihm wurde von einem weiteren Kunden ein Trick für reduzierten Speicherverbrauch vorgeschlagen. Diese Methode habe ich selbst noch nicht ausprobiert.


    Ist denn inzwischen bekannt was diese Fehlermeldung verursacht und wie sich das Problem effektiv beheben lässt :?:


    Gruß
    MMax

    Das ist keine Fehlermeldung. Ihr vServer verbraucht offenbar beim Start kurrzeitig einmal alle verfügbaren garantierten Ressourcen wozu es zu besagter Meldung im VCP kommt. Wenn Sie beim Systemstart z.B. einen Webserver, Datenbankserver und mehrere Gameserver starten lassen, ist dies nicht verwunderlich.

    Heute morgen war jedenfalls gegen 9 Uhr das Problem, dass beide CS: S-Server nach einem nicht regulären vServer-Neustart im automatischen Steam-Updateprozess festhingen - mir im netcup VServer Control Panel diese Fehlermeldung angezeigt wurde - während laut free -m das RAM Limit nicht erreicht war.

    Moin
    Diese Meldung (keine Fehlermeldung) sagt nur, das dein Server das RAM-Limit mindestens einmal voll ausgenutzt hat. Über die aktuelle Situation sagt das nichts aus.


    Die vServer sollten üblicherweise mit ihrem RAM auskommen. Gelegentliche Überschreitungen sind aber unproblematisch. Erst wenn das häufiger vorkommt, musst Du dir das ansehen und ggf. deine Konfiguration anpassen.


    Es kann sein, das deine Probleme mit den CS-Servern damit zusammenhängen. Das musst Du aber selber herausfinden. (Stw. Monitoring)
    Aus deiner Schilderung lässt sich das so nicht ableiten.


    Was sagen denn die LOG-Files deiner Server (CS, Apache).
    Läuft dein System mit nur einem CS-Server stabil.
    Hilft es, wenn Du die beiden Server nicht zeitgleich starten lässt.
    Hilft es, den Apache wegzulassen?
    [...]


    Mordor

    Zitat von Mordor

    Diese Meldung (keine Fehlermeldung) sagt nur, das dein Server das RAM-Limit mindestens einmal voll ausgenutzt hat. Über die aktuelle Situation sagt das nichts aus.


    Im netcup Wiki wird diese Meldung im Unterpunkt Fehler zum netcup VCP aufgeführt, weshalb ich eigentlich davon ausgegangen bin, dass es sich dementsprechend um eine Fehlermeldung handelt.


    Zitat von Mordor

    Die vServer sollten üblicherweise mit ihrem RAM auskommen. Gelegentliche Überschreitungen sind aber unproblematisch. Erst wenn das häufiger vorkommt, musst Du dir das ansehen und ggf. deine Konfiguration anpassen.


    Ist es nicht etwas unwahrscheinlich, dass ein vServer mit installiertem Debian OS ohne Desktopumgebung, mit einem einfachen Webserver ohne Datenbank, PHP oder ähnlichem sowie zwei CS: S-Servern diese Grenze erreicht? Schließlich werden nach einem erfolgreichen Start bei weitem keine 2GB RAM benötigt. Mein Kollege erhielt diese Meldung bereits am 25.01.2012.


    Zitat von Mordor

    Was sagen denn die LOG-Files deiner Server (CS, Apache).


    access.log von apache2

    Code
    209.172.57.250 - - [30/Jan/2012:08:07:48 +0100] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 323 "-" "-"


    error.log von apache2

    Code
    [Mon Jan 30 08:07:48 2012] [error] [client 209.172.57.250] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Mon Jan 30 08:18:51 2012] [notice] caught SIGTERM, shutting down


    Bei „w00tw00t.at.ISC.SANS.DFind“ handelt es sich laut dieser Seite um die Anfrage eines Vulnerability Scanners.


    In den Logs vom 1. CS: S-Server gibt es zwischen 01:41 Uhr und 09:12 Uhr keine Einträge, da wohl in dieser Zeit kein Spieler den Server besucht hat und danach der Server neu gestartet wurde. Der 2. Server hat den letzten Eintrag 07:38 Uhr, nachdem ein Spieler kurzzeitig den Server betrat und dann erst wieder 09:12 Uhr.

    Code
    L 01/30/2012 - 09:12:32: Log file started (file "logs/L0130003.log") (game "/home/*****/*****/css/cstrike") (version "4785")
L 01/30/2012 - 09:12:33: [META] Loaded 1 plugin.
L 01/30/2012 - 09:12:33: Log file closed


    Zitat von Mordor

    Läuft dein System mit nur einem CS-Server stabil.


    Nicht ganz. Der 2. CS: S-Server läuft erst seit dem 15.01.2012. Bei dem anderen Server hatte sich seit November 2011 ein paar mal der srcds_linux Prozess mit über 100% Last aufgehängt.


    Zitat von Mordor

    Hilft es, wenn Du die beiden Server nicht zeitgleich starten lässt.


    Das mit dem Neustart klappt ja in der Regel und bisher wird die Meldung seit mehr als 8 Stunden nicht im netcup VCP ausgegeben.


    Zitat von Mordor

    Hilft es, den Apache wegzulassen?


    Auf den würde ich eigentlich nur ungern verzichten, aber evtl. werde ich das noch ausprobieren.

    Unter Netcup VServer Control Panel – netcup Wiki (Informationen) wird jedoch darauf hingewiesen das dies eine Status-Anzeige, keine Fehlermeldung ist. Die "rote Box" besagt viel mehr das es sich um kritische Informationen handelt, dies werden wir im Wiki noch ausbessern / besser erwähnen.


    Wenn einer der Gameserver nicht stabil funktioniert und dort ggf. auch Plugins / Erweiterungen verwendet werden, kann dies schon eine Ursache sein. Auch ist es durchaus normal das ein vServer mit einem Webserver und 2 Gameservern beim Start viel RAM verbrauchen kann.


    Beispiel: In einem kürzlichen Test mit einem anderen Gameserver (ich nenn den Namen jetzt bewusst nicht), verbraucht dieser im laufenden Betrieb ca. 400-600MB RAM. Beim Start, wo viel Informationen initialisiert werden wie dies bei Gameservern durch die Bank weg geschieht, verbraucht der Prozess beinahe das 10fache an Arbeitsspeicher.

    Nach 20 ½ Stunden Laufzeit habe ich jetzt noch einmal die RAM-Auslastung kontrolliert. Im netcup VCP erscheint bisher "kein neuer Status vorhanden" bzw. ist die Meldung seit gestern nicht mehr erschienen.


    free -m

    Code
    total       used       free     shared    buffers     cached
Mem:          2048       2048          0          0          0       2024
-/+ buffers/cache:         23       2024
Swap:         2048          0       2048

    Was mich hierbei verwundert sind die nur ca. 23 MB die derzeitig vom System auch tatsächlich verwendet werden.


    top

    Code
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 21** ********  20   0  271m 122m  19m S    8  6.0 222:32.06 srcds_linux
 26** ********  20   0  254m 105m  19m S    3  5.1 113:44.00 srcds_linux

    Die beiden Prozesse belegen ca. 227MB (122MB+105MB) des physikalischen Arbeitsspeichers.


    Sind dann die ca. 23 MB des verwendeten Puffer nicht zuwenig oder wie muss ich diese Ausgabe interpretieren :?:


    Zitat von [netcup] Alex

    Wenn einer der Gameserver nicht stabil funktioniert und dort ggf. auch Plugins / Erweiterungen verwendet werden, kann dies schon eine Ursache sein.

    Der erste CS: S-Server war lange Zeit über mehrere Tage und Wochen ohne Unterbrechung durchgelaufen. Als so genannte Addons verwenden wir MetaMod: Source v1.8.7 und SourceMod v1.4.1. Dabei handelt es sich um die neusten stabilen Versionen. Der Fehler der beim ersten Server seit November auftritt äußerte sich bisher anders.
    Das CS: S-Server insbesondere nach neuen Updates fehlerhaft laufen können, ist bekannt, allerdings halte ich das in dem Fall für etwas unwahrscheinlich, da das letzte Update schon etwas zurückliegt und wohl auch andere ein derartiges Problem melden würden.


    Zitat von [netcup] Alex

    Auch ist es durchaus normal das ein vServer mit einem Webserver und 2 Gameservern beim Start viel RAM verbrauchen kann.

    Die 2 GB an verwendetem RAM kommen mir in diesem Fall dennoch etwas seltsam vor, zumal ich vor längerer Zeit auch schon mal einen weiteren Server zum Testen im Autostart hatte und diese Meldung währenddessen nicht erschien.

    Dragon
    Wenn ich das dort richtig verstehe, dann wird das hier dargestellte Verhalten mit diesem Trick nachgestellt.
    Aber was kann ich jetzt damit anfangen :?:


    Inzwischen ist der Wert des verwendeten Puffer noch weiter gesunken. 8|


    free -m

    Code
    total       used       free     shared    buffers     cached
Mem:          2048       2048          0          0          0       2041
-/+ buffers/cache:          6       2041
Swap:         2048          0       2048

    Also sind die Angaben unter "free -m" nicht verwertbar und ich muss mich auf die der einzelnen Prozesse verlassen. :pinch:


    top

    Code
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 21** ********  20   0  272m 123m  19m S   29  6.0 275:24.41 srcds_linux
 26** ********  20   0  254m 105m  19m S   12  5.2 137:06.66 srcds_linux


    Die sind im Vergleich zu denen vor 7h nahezu unverändert. :whistling:


    Nachtrag von 20:24 Uhr:
    Mein Kollege teilte mir eben noch mit, dass er gestern früh eine E-Mail von netcup erhalten hat bzgl. Wartungsarbeiten am Node.
    Das erklärt nun auch die Unterbrechung, da diese Arbeiten für die Zeit zwischen 8 und 9 Uhr angesetzt waren und ein Update des Kernels beinhalteten.


    Der vServer verwendet nun die folgende Kernel-Version: uname –r

    Code
    3.0.18-vs2.3.2.2-nc

    Vorhin viel mir auf, dass einer unserer CS: S-Server nicht mehr erreichbar war, da er sich aufgehängt hatte. Das Verhalten hatte ich bereits bei #5 geschildert.

    Zitat von MMax


    Nicht ganz. Der 2. CS: S-Server läuft erst seit dem 15.01.2012. Bei dem anderen Server hatte sich seit November 2011 ein paar mal der srcds_linux Prozess mit über 100% Last aufgehängt.


    top


    Laut Log-Eintrag muss sich der entsprechende CS: S-Server mit 102% CPU-Last gegen 21:30 Uhr aufgehängt haben. Den Prozess habe ich dann gegen 01:08 Uhr neu gestartet.


    top

    Code
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
12*** ********  20   0  228m  79m  19m S    6  3.9   3:08.13 srcds_linux
25*** ********  20   0  272m 116m  17m S    4  5.7 362:57.22 srcds_linux


    free -m

    Code
    total       used       free     shared    buffers     cached
Mem:          2048       2048          0          0          0       1873
-/+ buffers/cache:        174       1873
Swap:         2048          0       2048


    Sieht auch soweit ok aus, dennoch steht im netcup VCP:

    Zitat

    Seit dem letzten Start hat Ihr VServer mindestens einmal sein RAM Limit ausgeschöpft.


    Außerdem wird der RAM Verbrauch dort mit rot angegeben.


    Müsste unter diesen Bedingungen der RAM Verbrauch nicht eigentlich mit grün angegeben werden?


    Wie ist diese Ausgabe nun zu interpretieren? ?(

    Dies wurde schon mehrfach erläutert und steht auch im Handbuch des VCP im Wiki.


    Die Anzeige ist kein "Live" Wert, sondern zeigt lediglich das seit dem letzten Start des vServers das RAM Limit mindestens ein mal vollständig ausgenutzt wurde.

    Stimmt, das steht dort.
    Ich hätte vermutet entgegen zur Meldung wird dort der aktuelle Status ausgegeben.
    Doch da lag ich wohl falsch. Da hätte ich mich natürlich besser im Wiki informieren können. ^^


    Wie der RAM so stark ausgelastet sein soll, das weiß ich zwar immer noch nicht, dennoch ist das Thema damit hier vorerst beendet.