Arbeitsspeicher läuft voll

  • GerhardSt;35246 wrote:

    Da muss ich wohl doch noch weitersuchen, oder kann es sein das da Fehler erst ca. einen Monat später auftretten?


    Vielleicht wurden die Probleme nicht nur durch den offensichtlichen Kernelwechsel verursacht. Gibt vielleicht auch noch andere Gründe die mitspielen, denn wie gesagt, ich habe die Probleme bisher nirgends. Vielleicht wurde auf den Nodes noch etwas anderes geändert, was wir als User nicht mitbekommen, da damit z.B. kein Neustart verbunden ist. Keine Ahnung...


    EDIT: Oder es liegt an der vServer Serie und den Unterschieden davon. Welchen vServer habt ihr beide denn?



    MfG Christian

  • Guten Abend,


    Ich habe genau das selbe Problem.
    Ich nehme mal an das hängt mir dem Webserver zusammen, vielleicht ist es auch ISPCP schuld. Nach vielen Besuchen steigt die Auslastung.
    Nach ca. 4 Tagen bin ich oft schon auf 100%iger Auslastung.


    Meine momentane Lösung ist "shutdown -r now" als Crontab.
    Hat vielleicht jemand eine Lösung?


    Danke!

  • Guten Abend Lawliet,


    könntest du uns bitte noch mitteilen, welchen vServer du hast.


    Mit ISPCP dürfte das Problem scheinbar nicht direkt zusammenhängen, da P4G0 was anderes einsetzt, oder habe ich da was überlesen?
    Ist es bei dir auch so, das alles normal läuft, wenn du das Backup deaktivierst?


    Vielleicht finden wir ja so herraus, woran es liegt.

  • Also am ISPCP kann es bei mir nicht liegen, ich setze ein pures Ubuntu ohne irgendeine Admin-Software ein. Ich habe sogar extra einmal alles mit Debian versucht, dort dasselbe Problem.


    Deshalb denke ich stark, dass es an einem Kernel oder anderweitig mit der Virtualisierungssoftware im Zusammenhang steht. Was mich halt nervt, ist, dass alles fast ein Jahr problemlos lief und auf einmal - selbst nach einer Neuinstallation und zwei verschiedenen Images - verrückt spielt.

  • Nabend,


    So genau kann ich das nicht sagen, ich denke wie P4G0 das es doch eigentlich nicht am ISPCP liegt.
    Ich habe von Netcup den "vServer Uranus".


    Ich sehe die Situation so:
    1. Der Server Startet normal, Ram Auslastung (Standard bei 9%)
    2. Nach Tagen stopft sich der Cache schnell voll, Besucherzahl bei -30 im Monat
    3. Cache bleibt erhalten löscht sich aber nicht selbstständig.


    Für mich sieht es so aus als würde es mehr daran liegen das Debian /apache oder was auch immer die Temporären Dateien nicht löscht.
    Laut. Debian sind nämlich die Anwendungen die wenigsten Auslaster...

  • Also wenn ich das so sehe, schon drei Leute mit demselben Problem. Da scheint was man Memory Management des Kernels schief zu laufen.


    Ihr nutzt nicht zufällig mysqldump und/oder rsnapshot?


    Ich hab übrigens festgestellt, dass der cache auch ziemlich vollgelaufen ist, als ich einen größeren MySQL-Dump eingespielt habe. Scheint mir wohl hauptsächlich ein Problem mit MySQL zu sein und das hat ja so gut wie jeder installiert...

  • P4G0;35189 wrote:

    Weiterhin habe ich herausgefunden, dass der RAM genau um Mitternacht weiter volläuft


    Das ist natürlich eine sehr passende Zeit für einen cronjob egal welcher Art auf einem vServer:confused: vServer: bestimmte Intervalle: 1 (2te Liste, abs. 6. Spalte ist der I/O-Wait), 2



    P4G0;35492 wrote:

    Ich hab übrigens festgestellt, dass der cache auch ziemlich vollgelaufen ist


    Das ist positiv, das zeigt nämlich das der Cache funktioniert.


    Ich habe es gerade selbst getestet, mit einem find kann ich den I/O-Wait um über 10 anheben. Was wohl rsnapshot macht? ;)


    P4G0, Lawliet: Könnt ihr mal konkrete Daten posten? Denke das Problem ist sicherlich lösbar.

  • Was spricht denn gegen eine Sicherung um 00:00 Uhr? :)
    Was meinst du mit "konkreten Daten"? Pro Sicherung bestehend aus rsnapshot + mysqldump werden 300MB RAM als Cache beschlagnahmt und nach der Sicherung nicht mehr freigegeben. Nach spät. 3 Tagen ist dann bei 1GB RAM Ende.


    Ansonsten laufen nur Apache, Subversion, Postfix und Dovecot auf dem Server.


    Sobald ich die Sicherung deaktiviere, treten keine Probleme mehr auf. Und wie ich zig mal geschrieben habe: das lief alles fast ein Jahr lang ohne Probleme. Auf einmal solche Macken, die sich trotz Neuinstallation und dem Test eines anderen OS-Images nicht beheben lassen.


    Sobald der Cache rund 800MB (free -m) gefressen hat, wird dann auch im VCP eine RAM-Warnung ausgegeben. Die letzten paar MB würde sich der Cache sicherlich auch noch schnappen, wäre der Rest nicht von den Serverdiensten belegt.

  • P4G0;35495 wrote:

    Was spricht denn gegen eine Sicherung um 00:00 Uhr? :)


    Das habe ich doch verlinkt.


    P4G0;35495 wrote:

    Was meinst du mit "konkreten Daten"?


    Benutzte Software mit welchem Versionsstand, wie konfiguriert (vor allem hinsichtlich Speicherverbrauch). Du schreibst selbst

    P4G0;35199 wrote:

    Nach 2 bis 3 Tagen ist dann Sense

    Wie sieht das System denn nach 2 Tagen aus? free/ps?


    P4G0;35495 wrote:

    Ansonsten laufen nur Apache, Subversion, Postfix und Dovecot auf dem Server.


    Nach 1,5 Wochen immerhin ein paar Anhaltspunkte. Mein System bietet ähnliche Dienste an. Die Software habe ich so eingerichtet, dass diese auch auf einem vServer mit wenig RAM laufen kann. In der Standardkonfiguration würde jeder einzelne Dienst bei mir locker 2GB RAM belegen. Daher ja auch die Frage nach der Konfiguration.


    P4G0;35495 wrote:

    Sobald ich die Sicherung deaktiviere, treten keine Probleme mehr auf.


    Was passiert denn, wenn du per Hand die Sicherung anstartest?


    P4G0;35495 wrote:

    Und wie ich zig mal geschrieben habe: das lief alles fast ein Jahr lang ohne Probleme. Auf einmal solche Macken, die sich trotz Neuinstallation und dem Test eines anderen OS-Images nicht beheben lassen.


    Siehe u.a. oben bei konkrete Daten.

  • Also bei mir tritt das Problem immer sofort, durch die automatische Sicherung des ISPCP kurz nach Mitternacht auf. Aber auch wenn ich die Sicherung manuell starte, geht im CCP das rote Lämpchen an. Bei deaktivierter Sicherung, läuft alles ohne Probleme.

  • Alex


    Ja, sicher! Nur warum ist das plötzlich so, wenn an der Sicherung eigentlich nichts geändert wurde. Klar, die Datenmenge steigt Tag täglich, nur warum haben das Problem dann hier mehrere? Laut Auskunft vom ISPCP-Forum dürfte es mit meiner Datenmenge, kein Problem mit dem RAM geben. Jetzt frag ich mich, was ich dagegen machen kann.

  • Also inzwischen ist mir aufgefallen, dass sämtliche IO-lastigen Prozesse den Cache vollstopfen und nicht wieder freigeben. Bei folgenden Szenarien ist es mir aufgefallen (unabhängig der Uhrzeit):


    - MySQL-Dump einspielen
    - MySQL-Dump erstellen
    - Datensicherung mit rsnapshot
    - Piwik-Logs per cronjob aufbereiten
    - Testweise Installation des Source Dedicated Server (bereits nach einer Minute Installation ist der gesamte Cache voll - es werden viele Dateien heruntergeladen)


    Getestet habe ich bereits unter folgenden Betriebssystemen:
    - Debian Squeeze 64-Bit
    - Ubuntu 10.04 64-Bit
    - Ubuntu 11.04 64-Bit


    Ich habe nach wie vor ein Kernelupdate in Verdacht, da das System ohne Änderung diese Probleme erst plötzlich zeigte, wobei bis auf Sicherheitsupdates ein Jahr lang nichts verändert wurde. Zudem tritt der Fehler ja auch auf verschiedenen Betriebssystemen direkt nach der Neuinstallation auf.


    Ich würde mich echt freuen, wenn das behoben werden könnte... So langsam geht mir das dauernde Neustarten des Servers auf den Zeiger. Ich habe inzwischen sämtliche cronjobs deaktiviert, damit das Problem sich möglichst lange verzögert. Dementsprechend habe ich auch schon seit geraumer Zeit kein ordentliches Backup mehr erstellt.