Hi @ll,
ich bastele jetzt schon seit drei Uhr an meinem vServer Max von server4you rum, weil ihm ständig der Speicher ausgeht. Und das schlimme ist: Ich habe heute überhaupt nichts geändert. Betriebssystem ist RedHat 9 mit Confixx.
Auf das Problem bin ich aufmerksam geworden, weil ich keine Mails mehr abholen konnte (Timeout beim Verbindungsaufbau). Login per SSH ging auch nicht (Connect timed out), FTP auch nicht. Statische Webseiten wurden normal ausgeliefert, .php-Dateien nicht. Ping normal.
Nach einem Reboot lief zuerst wieder alles. Nach 5 Minuten stellte sich aber der alte Zustand wieder ein. Nach einem weiteren Reboot habe ich mich dann per SSH eingeloggt und "top" beobachtet. Dort konnte ich beobachten, dass der httpd 99.9% CPU-Nutzung hat, und der freie Speicher immer weniger wurde.
Nach einem weiteren Reboot habe ich dann erstmal den Apache gestoppt und die Logfiles durchforstet. error_log: keine Einträge von heute. access_log: nur ab und zu Abrufe von statischen Seiten und Bildern. ssl-Logs auch ohne Befund.
Als nächstes habe ich dann über eine SSH-Sitzung die /proc/user_beancounters beobachtet und über eine weitere Verbindung den Apache gestartet. Vor dem Start lag der Wert von privvmpages bei ungefähr 6500, und direkt nach dem Start des Apache ging er hoch auf über 60000. Nach 1-2 Minuten begann er sich kontinuierlich zu erhöhen, bis um Limit. Bei einem failcnt von 16000 habe ich dann den nächsten Reboot angefordert...
Ich habe dann alle Dateien der Confixx-User (web1, web2, ...) aus /var/www verschoben. Damit lief der Apache stabil. Dann habe ich Verzeichnis für Verzeichnis wiederhergestellt, den Apache jeweils neugestartet und abgewartet. So kam ich auf ein Verzeichnis mit relativ simplen PHP-Scripten. Wenn die Dateien an der für den Apache richtigen Stelle lagen, ging der privvmpages-Wert direkt nach dem Start auf 60000 und mehr. Waren die Dateien an einen anderen Ort außerhalb des DocumentRoot verschoben, blieb der Wert zwischen 8000 und 10000 stabil.
Dann habe ich alle Dateien aus dem betreffenden Verzeichnis nacheinander zurückgeschoben, jeweils wieder Apache neugestartet, gewartet. Das Ende vom Lied: Wenn alle Dateien am alten Platz waren, erzeugte es den hohen privvmpages-Wert. Fehlte eine beliebige (!) Datei, lief alles normal.
Wie gesagt, ich habe seit gestern nichts an den Dateien geändert. Es gab laut Logfiles auch keine Zugriffe per SSH oder FTP. Ebenso wurden die Scripte aus dem verdächtigen Verzeichnis laut access_log nicht von außen aufgerufen.
Das beste kommt allerdings jetzt: Wenn ich das Verzeichnis z.B. in Verzeichnis2 umbenenne, läuft alles. Obwohl die darin befindlichen Dateien vollkommen unangetastet bleiben. So läuft es jetzt seit 2 Stunden stabil.
Meine aktuellen beancounter:
Bin für jede Idee dankbar
Danke & Gruß,
PS: Falls das hier nicht hingehört, bitte verschieben...
ich bastele jetzt schon seit drei Uhr an meinem vServer Max von server4you rum, weil ihm ständig der Speicher ausgeht. Und das schlimme ist: Ich habe heute überhaupt nichts geändert. Betriebssystem ist RedHat 9 mit Confixx.
Auf das Problem bin ich aufmerksam geworden, weil ich keine Mails mehr abholen konnte (Timeout beim Verbindungsaufbau). Login per SSH ging auch nicht (Connect timed out), FTP auch nicht. Statische Webseiten wurden normal ausgeliefert, .php-Dateien nicht. Ping normal.
Nach einem Reboot lief zuerst wieder alles. Nach 5 Minuten stellte sich aber der alte Zustand wieder ein. Nach einem weiteren Reboot habe ich mich dann per SSH eingeloggt und "top" beobachtet. Dort konnte ich beobachten, dass der httpd 99.9% CPU-Nutzung hat, und der freie Speicher immer weniger wurde.
Nach einem weiteren Reboot habe ich dann erstmal den Apache gestoppt und die Logfiles durchforstet. error_log: keine Einträge von heute. access_log: nur ab und zu Abrufe von statischen Seiten und Bildern. ssl-Logs auch ohne Befund.
Als nächstes habe ich dann über eine SSH-Sitzung die /proc/user_beancounters beobachtet und über eine weitere Verbindung den Apache gestartet. Vor dem Start lag der Wert von privvmpages bei ungefähr 6500, und direkt nach dem Start des Apache ging er hoch auf über 60000. Nach 1-2 Minuten begann er sich kontinuierlich zu erhöhen, bis um Limit. Bei einem failcnt von 16000 habe ich dann den nächsten Reboot angefordert...
Ich habe dann alle Dateien der Confixx-User (web1, web2, ...) aus /var/www verschoben. Damit lief der Apache stabil. Dann habe ich Verzeichnis für Verzeichnis wiederhergestellt, den Apache jeweils neugestartet und abgewartet. So kam ich auf ein Verzeichnis mit relativ simplen PHP-Scripten. Wenn die Dateien an der für den Apache richtigen Stelle lagen, ging der privvmpages-Wert direkt nach dem Start auf 60000 und mehr. Waren die Dateien an einen anderen Ort außerhalb des DocumentRoot verschoben, blieb der Wert zwischen 8000 und 10000 stabil.
Dann habe ich alle Dateien aus dem betreffenden Verzeichnis nacheinander zurückgeschoben, jeweils wieder Apache neugestartet, gewartet. Das Ende vom Lied: Wenn alle Dateien am alten Platz waren, erzeugte es den hohen privvmpages-Wert. Fehlte eine beliebige (!) Datei, lief alles normal.
Wie gesagt, ich habe seit gestern nichts an den Dateien geändert. Es gab laut Logfiles auch keine Zugriffe per SSH oder FTP. Ebenso wurden die Scripte aus dem verdächtigen Verzeichnis laut access_log nicht von außen aufgerufen.
Das beste kommt allerdings jetzt: Wenn ich das Verzeichnis z.B. in Verzeichnis2 umbenenne, läuft alles. Obwohl die darin befindlichen Dateien vollkommen unangetastet bleiben. So läuft es jetzt seit 2 Stunden stabil.
Meine aktuellen beancounter:
Code:
Version: 2.5
uid resource held maxheld barrier limit failcnt
xxxxxx: kmemsize 1829840 3082472 14112423 15523665 0
lockedpages 0 0 689 689 0
privvmpages 10329 150510 205810 226391 0
shmpages 2750 2791 27954 27954 0
dummy 0 0 0 0 0
numproc 26 37 172 172 0
physpages 3431 144863 0 2147483647 0
vmguarpages 0 0 64968 2147483647 0
oomguarpages 3431 144863 64968 2147483647 0
numtcpsock 12 36 344 344 0
numflock 1 6 550 605 0
numpty 4 4 32 32 0
numsiginfo 0 6 1024 1024 0
tcpsndbuf 8880 325996 3295117 4704141 0
tcprcvbuf 0 85360 3295117 4704141 0
othersockbuf 4440 13824 1647558 3056582 0
dgramrcvbuf 0 8536 1647558 1647558 0
numothersock 5 16 344 344 0
dcachesize 233261 290660 3077965 3170304 0
numfile 672 843 5504 5504 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 10 10 128 128 0Bin für jede Idee dankbar
Danke & Gruß,
PS: Falls das hier nicht hingehört, bitte verschieben...