Froschs Blog

Computer und was das Leben sonst noch so zu bieten hat

Zur Website | Impressum

Speicherfresser

17. November 2010 um 19:07 Uhr von Atari-Frosch

Als ich vor einem guten Jahr meinen dedizierten kleinen Server aufgab, um auf die VM bei einem Bekannten zu wechseln, hatte ich das vor allem deshalb getan, weil ich ab etwa drei Wochen nach dem Upgrade von Debian Etch auf Debian Lenny ein seltsames Phänomen feststellen mußte: Es lief einfach immer wieder das RAM voll, und wenn der Rechner mal anfangen mußte zu swappen, war er von der Geschwindigkeit her nicht mehr zu gebrauchen. Irgendwann war dann auch der Swap voll, und dann war Ende.

Bei einem der Vorfälle hatte ich noch die Chance, draufzukommen und in die Prozeßliste zu schauen, bevor nichts mehr ging. Dabei stellte ich fest, daß der apache2 übermäßig viel RAM beanspruchte. Die Logs gaben aber keine ungewöhnlich hohen Zugriffszahlen auf die gehosteten Websites und (WordPress-)Blogs her.

Nachdem ich den Rechner ausgelöst und hier untersucht hatte, stellte ich fest, daß der zweite RAM-Riegel (256 MB, aufgeteilt auf 2 x 128 MB) nicht mehr in Ordnung war. Damit, so dachte ich, sei das Rätsel gelöst: Wenn er im defekten RAM nicht weiter nach hinten kommt, geht er vielleicht viel früher auf den Swap, als er eigentlich müßte.

Aber damit war es wohl leider nicht getan.

Die virtuelle Maschine, auf der das System nun liegt, hat doppelt so viel RAM und ein Vielfaches an CPU-Kapazität.

Die Last beim Apachen im Normalzustand sieht ungefähr so aus:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ PPID COMMAND

 8768 www-data 20 0 165m 26m 3928 S 0 5.4 0:02.90 2252 apache2

 8808 www-data 20 0 170m 30m 3904 S 0 6.2 0:04.18 2252 apache2

 9256 www-data 20 0 170m 30m 3912 S 0 6.4 0:02.58 2252 apache2

 9676 www-data 20 0 171m 30m 4308 S 0 6.3 0:02.98 2252 apache2

11256 www-data 20 0 160m 21m 3828 S 0 4.3 0:00.76 2252 apache2

Das ist schon nicht wenig. Wenn die Maschine in den Überlastungszustand kommt, werden da noch mehr Apache-Prozesse draus, und das könnte dann durchaus eng werden. Am 22.09.2009, noch auf dem alten Server, hatte ich gerade noch rechtzeitig gemerkt, daß das RAM wieder volläuft, und festgestellt:

Apache will allein 250 MB haben. Ich restarte den Webserver, damit kommt er auf 165 MB runter, klettert aber sehr schnell wieder hoch.

Direkt nach einem Neustart liegt die gesamte RAM-Auslastung im System bei 170 MB (von 512) und schwankt in den ersten Stunden zwischen 170 und 220 MB. Danach geht sie auf zwischen 340 und 460 MB hoch, überschreitet aber normalerweise nicht die 500-MB-Grenze.

Ich hatte am letzten Wochenende zusätzlich noch die Mailinglisten-Software mailman installiert. Dieses Python-Programm hat ebenfalls einen recht netten RAM-Bedarf, wie ich mittlerweile weiß. Jedenfalls lief das RAM wieder voll, der übergeordnete Host hatte eine CPU-Load von 40, die VM reagierte nicht mehr sinnvoll und mußte abgewürgt werden. Allerdings konnte ich eines noch in der Prozeßliste sehen: Wieder gab es übermäßig viele Apache-Prozesse, ohne daß es erhöhte Zugriffszahlen gegeben hatte. Beim Mailman konnte ich dagegen nur ablesen, daß er zwar 6 oder 7 Prozesse offen hatte, diese jedoch vor allem CPU-Zeit verbraucht hatten (jeweils zwischen 25 und 30 Sekunden innerhalb von zwei Tagen). Der RAM-Verbrauch war pro Prozeß deutlich niedriger als beim Apachen.

Den Mailman lasse ich jetzt erstmal aus, dabei hätte ich den eigentlich gebraucht (logisch, sonst hätte ich ihn nicht installiert ...). Nun wüßte ich gern, was mir da seit dem Update auf Lenny immer wieder das RAM auffüllt. apache2 allein kann es wohl eher nicht sein, denn dann hätten ja noch viel mehr Leute das Problem — oder rebootet Ihr Eure Server sowieso alle zwei Wochen? 😉

Also: Unter dem Apachen laufen zwei WordPress-Installationen (einmal 2.9.2 nativ und einmal 2.9.2 in deutsch), von denen nur die native wirklich genutzt wird (das ist diese hier). Damit laufen natürlich auch PHP5 (Pakete: php5, php5-common, php5-mysql) und MySQL-Server und -Client. Bis auf WordPress selbst stammen die Pakete aus dem Debian-Repository und sind, auf dieses bezogen, aktuell.

In /etc/apache2.conf habe ich auf Anraten folgendes eingetragen:

<IfModule mpm_prefork_module>
 StartServers 2
 MinSpareServers 3
 MaxSpareServers 5
 MaxClients 50
 MaxRequestsPerChild 500
</IfModule>

Das memory_limit für PHP steht bei 64 MB (default: 128 MB). Diese Änderung hatte ich bereits vor einiger Zeit im Hinblick auf dieses Problem vorgenommen.

Ansonsten laufen da noch ein postfix, ein dovecot, ein ZNC, ein eggdrop, ein irssi im screen, sshd (klar), icecast2, ntp und bitlbee. Keins davon ist mir vom RAM-Verbrauch her und insbesondere mit steigendem RAM-Verbrauch bislang irgendwie aufgefallen.

Tritt das Problem noch woanders auf? Hat vielleicht sogar schon jemand eine Lösung gefunden?

Ich habe beim Suchen eine Bugmeldung gefunden, die ich vor einem guten Jahr allerdings noch nicht sicher meinem Problem zuordnen konnte. Es sieht immer mehr danach aus, als ob es passen würde; ich habe denn auch ein Update eingesandt. Ich frage mich allerdings: Wenn das Problem so lange bekannt ist und die Kombination aus apache2 und PHP5 unter Debian Lenny doch nicht ganz so selten sein dürfte — wie gehen andere damit um, und warum wird das nicht repariert?

8 Kommentare zu “Speicherfresser”

  1. Schlipsnerd quakte:

    Hallo Frosch,

    probier doch mal die Kombination von http://de.php.net/manual/de/install.unix.lighttpd-14.php und http://redmine.lighttpd.net/wiki/lighttpd .

    Damit sollte es möglich sein, sowohl einen einfachen Webserver als auch PHP an den Start zubringen, das brauchst du ja für WordPress.

    Eigene Erfahrungen hab ich aber damit noch nicht gemacht.

    Mfg,

    Schlipsnerd


  2. bed quakte:

    Bei mir sieht es mit Apache2 eigentlich nicht schlecht aus:
    [code]
    Private + Shared = RAM used Program

    2.7 MiB + 649.5 KiB = 3.3 MiB saslauthd (5)
    3.2 MiB + 206.5 KiB = 3.4 MiB munin-node
    4.3 MiB + 320.0 KiB = 4.6 MiB vlogger
    4.8 MiB + 332.0 KiB = 5.1 MiB imapd (3)
    6.2 MiB + 255.5 KiB = 6.5 MiB fail2ban-server
    6.5 MiB + 122.0 KiB = 6.7 MiB mailmanctl
    6.4 MiB + 310.5 KiB = 6.7 MiB ts3server_linux_amd64
    7.2 MiB + 108.5 KiB = 7.3 MiB wineserver
    10.6 MiB + 355.5 KiB = 11.0 MiB postgrey
    14.0 MiB + 105.5 KiB = 14.1 MiB freshclam
    10.6 MiB + 9.9 MiB = 20.5 MiB apache2 (12)
    6.2 MiB + 37.7 MiB = 43.9 MiB spamd (3)
    59.8 MiB + 94.0 KiB = 59.9 MiB wopded.x86_64
    92.7 MiB + 6.5 MiB = 99.2 MiB php-cgi (5)
    104.0 MiB + 2.5 MiB = 106.5 MiB python2.5 (8)
    96.8 MiB + 50.9 MiB = 147.7 MiB amavisd-new (3)
    198.2 MiB + 45.0 KiB = 198.2 MiB etqwded.x86
    278.0 MiB + 278.5 KiB = 278.3 MiB mysqld
    375.5 MiB + 1.0 MiB = 376.6 MiB il2server.exe
    1.4 GiB + 673.0 KiB = 1.4 GiB bf2 (2)
    [/quote]
    Ist ein Lenny System
    für Apache 20MB sieht doch ganz gut aus, da sind die Gameserver schon ganz anderes Kaliber.


  3. frosch quakte:

    @Schlipsnerd: Wäre eine Möglichkeit, wenn lighttpd alles macht, was ich so brauche (z.B. auch mehrere Domains/Subdomains hosten). Ich bin allerdings froh, daß ich ein System prinzipiell am Laufen habe. Mich in was Neues einarbeiten ist immer so eine Sache, da steht oft die Gesundheit vor (Konzentrationsprobleme wegen chronischer Depression). Ich behalt’s aber mal im Hinterkopf und hoffe, daß ich im neuen Jahr mal etwas mehr Ruhe für solche Dinge habe.


  4. frosch quakte:

    @bed: Mit was für einem Programm hast Du denn diese Liste erstellt? Das sieht interessant aus, und vor allem übersichtlicher als top/htop.

    Du benutzt php-cgi, nicht php5-mysql und php5/php5-common, sehe ich das richtig? Möglicherweise gibt es da ja einen Unterschied. Laut der Bugmeldung bei Debian betrifft das Problem ja die Kombination apache2/php5 (daß mysql eine Rolle spielen könnte, wurde bislang nicht in Betracht gezogen).


  5. bed quakte:

    Nee, ich benutze dreierlei php, suphp fast-cgi und den normalen phpmod das kommt auf die Einstellungen im _Site Setup an (ispconfig 3)
    das Tool ist ein python script
    wget http://www.pixelbeat.org/scripts/ps_mem.py

    Ist etwas aussagekräftiger, aber nicht unfehlbar. Aber was ist das schon 😉


  6. Daniel quakte:

    Ich teste momentan Nginx auf einer relativ kleinen Maschine.
    ISt zwar etwas umständlicher wie apache, verbraucht aber wesentlich weniger Arbeitsspeicher.


  7. kero quakte:

    Das hatte ich bei meiner alten XEN VM auch. Helfen soll angeblich auf apache2 worker umstellen oder mehr Speicher. Ich habe schliesslich den Provider gewechselt und habe nun statt 768MB 2GB. Leider habe ich nun Virtuozzo statt XEN, aber wenn ich ehrlich bin ist mir das auch egal, die Maschine laeuft stabil und darauf kommt es an.


  8. frosch quakte:

    @kero: Das Problem tritt unabhängig davon auf, ob der apache2 mit php5 auf einem virtuellen oder nativen System läuft. Mehr Speicher verzögert den Crash nur, kann ihn aber vermutlich nicht verhindern. Außer den Beschreibungen in der Bugmeldung bei Debian kenne ich es jetzt von zwei nativen und einem virtuellen System, mit 256 (nativ), 500 (nativ) und nochmal 500 (virtuell) MB an RAM.

    Ich habe selbst gerade wieder auf ein natives System gewechselt (1 GB RAM) und warte mal ab, ob das Problem wieder auftritt. Vielleicht wird es jetzt seltener, aber ich muß wohl weiterhin damit rechnen, denn das Grundproblem ist ja noch nicht gelöst, weil die Ursache noch nicht gefunden werden konnte — und das wiederum, weil der Fehler nicht reproduzierbar ist.

    Der worker ist nicht wirklich eine Lösung, weil dann wieder andere Pakete gelöscht werden, die ich jedoch brauche. Ich weiß leider gerade nicht auswendig, welche, das müßte ich bei Interesse nochmal nachgucken.

    Gruß, Frosch


Kommentieren

Bitte beachte die Kommentarregeln!

XHTML: Du kannst diese Tags verwenden: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>