Beiträge von P4G0

Nein, am Apache liegt es nicht. Selbst wenn ich den vServer neustarte, alle Dienste herunterfahre und dann irgendwas IO-lastiges starte (Backup, Archivierung, Datenbank-Dump, whatever), wird der komplette RAM für den Cache beansprucht und danach nicht mehr richtig freigegeben. Würde der Cache sich leeren, sobald ein Prozess neuen RAM allokieren muss, wäre alles Paletti, aber der Cache beharrt regelrecht auf den RAM, sodass nur ein Neustart hilft.

Hallo Leute,

ich schreibe mal wieder Aufgrund von RAM Problemen, die bereits seit einiger Zeit bestehen, mir jedoch niemand helfen kann. Auf meinem vServer laufen derzeit nur der Apache HTTP Server (u.a. mit mod_svn), MySQL, Postfix und Dovecot.

Nun wollte ich seit langem mal wieder ein Backup ziehen. Da der RAM immer voll läuft, wenn ich ein Backup mit mysqldump + rsnapshot starte, habe ich das automatische Backup nämlich mittlerweile deaktiviert.

Auf jeden Fall bestehen die RAM Probleme weiterhin. Bei jeglichen Anwendungsfällen mit hoher IO-Last läuft der RAM voll. Eben habe ich z.B. den vServer neugestartet, danach ist erst einmal alles einwandfrei. Dann habe ich mein (vor dem Neustart erstelltes) Backup ganz einfach mit tar archivieren wollen, doch die Erzeugung des tar-Archivs dauert Ewigkeiten, da der RAM währenddessen wieder voll läuft.

Das VCP meckert ebenfalls rum, dass der RAM voll ausgelastet ist. Mittlerweile bin ich echt genervt und überlege, zu einem anderen Provider zu wechseln, da ich auch Webseiten von anderen Personen hoste und diese nunmal automatisch gesichert werden sollen.

Vielleicht habt ihr ja eine Idee. Wie ich in anderen Threads bereits vor einiger Zeit geschrieben habe, trat das Problem direkt oder kurz nach einem Kernel Upgrade auf, bei dem "die RAM-Verwaltung verbessert" worden sei.

Update: habe ganz vergessen zu erwähnen, dass der RAM auch nach den IO-lastigen Prozessen ausgelastet bleibt und die Maschine träge reagiert - erst ein Neustart hilft dem vServer wieder auf die Beine (ja, ich weiß, dass gecached wird, aber es nützt mir nichts, wenn der Cache NIE mehr freigegeben wird und der RAM nicht mehr von anderen Anwendungen allokiert werden kann).

Gruß
Patrick

a) Ich kann diese Warnung im SCP ohne Probleme sofort nachstellen (diese erscheint sofort, wenn Cache den RAM frisst)
b) Der Server wurde bei 600MB Cache (in der zweiten Zeile von free -m also rund 600MB "free") schon diverse male neugestartet, weil der RAM angeblich dauerhaft ausgelastet war.

Ich habe nichts dagegen, wenn das System so viel cached, aber wenn der Server dadurch träge reagiert, das SCP rumjammert und der Server neugestartet wird, ist das nicht akzeptabel.
Zumal ich in dem oben verlinkten Thread bereits beschrieben habe, dass dieses Verhalten auf einmal auftrat, ohne irgendwelche Änderungen am System zu machen, sehr wohl aber kurz nach einem Kernel-Update eurerseits. Auch eine Neuinstallation + 3 verschiedene Betriebssysteme halfen nichts - der Fehler kommt immer sofort wieder.

Allerdings wurde mein vServer bereits mehrfach von der virtualisierungslösung durch dieses Problem automatisch neugestartet; habe uch schon vom Support eine E-Mail bekommen, dass der RAM ausgelastet war und der Server neugestartet werden musste.

Auch jetzt meckertd das VCP wieder, dass der RAM voll ist,wobei bei free -m in der zweiten Spalte 626MB feier RAM angezeigt werden.

Hallo Leute,

ich habe schon vor einiger Zeit einen Thread zu dem besagten Problem eröffnet, leider wurde mir bis heute keine Erklärung / Lösung für mein Problem geliefert. In dem älteren Thread schrieb ich, dass der RAM nur voll läuft, wenn ich rsnapshot + mysqldump (meine Backup-Lösung) nacheinander benutze. Ich habe in letzter Zeit jedoch festgestellt, dass die Behauptung nicht richtig ist. Das Problem wird bei diesen Programmen nur am schnellsten sichtbar.

Der RAM-Cache läuft voll, sobald ich irgendwelche IO-lastigen Prozesse starte - egal ob in MySQL oder auf Dateisystemebene. Die Uhrzeit spielt dabei auch keine Rolle. So läuft der RAM z.B. auch bei der Verwendung von Tiny Tiny RSS nach ein paar Tagen voll - dabei prüft ein PHP-Script in regelmäßigen Abständen nach aktuellen News in Atom- und RSS-Feeds und speichert neue Einträge in die Datenbank.

Nach einem Lauf meines Backup-Scripts zeigt mir free -m folgendes:
[Blockierte Grafik: http://img508.imageshack.us/img508/1342/freem.png]

Mir wurde zunächst gesagt, das ist ganz normal, da nun der RAM-Cache greift. Allerdings wird dieser Cache nie mehr freigegeben. Das VCP meldet mir auch die Fehlermeldung: "Seit dem letzten Start hat Ihr VServer mindestens einmal sein RAM Limit ausgeschöpft." Diese Meldung soll afaik nur auftreten, wenn der RAM wirklich mal richtig voll gelaufen ist. Des Weiteren ist mir aufgefallen, dass der Swap meines vServers nie aktiv wird.

Das Problem habe ich übrigens auch nicht alleine, weitere Benutzer mit diesem Fehler finden sich in meinem oben verlinkten Thread.

Hat jemand eine Erklärung/Lösung parat?

Ich nutze übrigens den vServer 1000 mit Ubuntu 10.04 LTS 64-Bit.

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.

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.

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

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.

Ach bei der Aussage, dass nun alles rund läuft war ich wohl etwas verplant. Die MySQL-Sicherung war noch deaktiviert

Keine Ahnung, ob nun stillschweigend etwas geändert wurde, aber auf einmal sind die Probleme nicht mehr da und ich hab keinerlei Änderungen am Server vorgenommen

Also ich habe den vServer 1000.

Nein das nicht, aber es liegt definitiv am Backup. Ich habe das Ganze ja längere Zeit protokolliert und nur das Backup knallt den RAM mit Cache voll (das sah man bei Munin anhand der Free RAM-Kurve, die um Mitternach nach unten ging und auch nach dem Backup auf dem Level blieb).

Der vServer wird auch nicht sofort neugestartet, wenn der RAM einmal ausgelastet ist, sondern erst nach einiger Zeit.

Also wie man im Screencast sieht, läuft der Cache voll.

Der auslagerungsspeicher wird und wurde komischerweise vom vServer noch nie genutzt.. Dort steht immer total: 1GB, Used: 0, Available: 1GB

Das witzige ist ja, dass das Problem eigentlich nur so gravierend in Kombination von rsnapshot + mysqldump auftritt.

Hast du zu rsnapshot eine einfache Alternative? Sollte mir x Backups der letzten Tage vorenthalten und relativ simpel sein. rsnapshot finde ich ansonsten halt schön bequem, da man Dateien einfach ohne spezielle Befehle wiederherstellen kann (einfach kopieren).

KB19: Nach einem Neustart des vServers ist wieder alles paletti: es werden nur rund 150MB RAM von Web- und Mailserver beansprucht.

Nach 2 bis 3 Tagen ist dann Sense, wenn die Backups täglich laufen. Wenn das Backup nicht läuft, bleibt die RAM-Auslastung dauerhaft auf etwa gleichem Niveau.

Aber atop werde ich mir einmal anschauen...

Das wird nicht nötig sein. Wenn ich die Sicherung abschalte, dann tritt der Fehler nicht auf (bereits getestet).

Mit cacti habe ich den Server längere Zeit überwacht und konnte dementsprechend die Sicherung als Problemquelle feststellen. Pro Backup werden rund 300MB RAM mehr belastet und nicht wieder freigegeben. Dementsprechend is nach 2 bis 3 Tagen Ende (bei 1GB RAM).

Die Sicherung lief wie gesagt bis April fast ein Jahr lang problemlos, ohne den RAM auszulasten (bzw. nicht mehr freizugeben). Soweit ich weiß, wurde April ein neuer Kernel eingespielt, der "Verbesserrungen am RAM-Management" beinhaltet. Könnte dieser nicht auslöser des Problems sein?

Welche Backup-Software würden Sie mir empfehlen, um Verzeichnisse und MySQL-Datenbanken zu sichern?

Ich habe erst vor kurzem eine E-Mail vom Support bekommen, dass der vServer aufgrund hohem RAM-Verbrauches neugestartet worden ist.

Das Problem habe ich genau wie hier geschildert. Die vorgeschlagene Problemlösung war, Alternativen zu der Sicherung zu finden. Da ich diese Sicherung bereits seit einem Jahr problemlos betrieben habe und ich auch keine "außergewöhnlichen" Tools einsetze, bin ich nicht gewillt, eine andere Backup-Software einzusetzen.

Zudem erzeugt vor allem mysqldump den hohen Cache-Anteil. Gibt es dazu überhaupt eine ernstzunehmende Alternative?

Und wie kann ich erreichen, dass mein vServer bei vollem Cache nicht neugestartet wird?

Das VCP gibt mir nämlich eine Warnmeldung aus und nach einiger Zeit wird mein vServer neugestartet...

Ich habe mal einen kleinen Screencast dazu erstellt. Die Werte im linken kleinen Terminal stammen direkt aus /proc/meminfo:

http://files.techspread.de/netcup.m4v

mysqlbackup ist ein selbstgeschriebens Shellscript, welches ihr hier ansehen könnt: http://www.techspread.de/1356/mysql-datenbanken-sichern