Server langsam - zuviele Prozesse im Arbeitsspeicher?

[shredder01]

Hallo,

ich habe einen Rootserver mit openSuSE 11 und mit Plesk 9.2.1.
Zur Zeit kämpfe ich mit dem Problem, das der Server immer nach ein paar Tagen (dieses Mal hat er immerhin 6 geschafft) sehr langsam wird. Alle Zugriffe dauern mindestens 20 Sekunden und drüber.
Ich hab nun festgestellt das ps axu --sort:command über 1300 Prozesse ausgibt, dreiviertel davon als sleeping.
Ein Reboot bringt immer sofortige Abhilfe, danach gehen alle Zugriffe immer blitzschnell.
Aber das sollte ja nicht der normale Weg sein, oder?
Wenn ich top ausführe habe ich über lange Zeiten ein idle von 0.0%.
Bei free bekomme ich folgende Ausgabe:

total used free shared buffers cached
Mem: 4044636 1932228 2112408 0 94612 633268
-/+ buffers/cache: 1204348 2840288
Swap: 2104496 0 2104496

Die Ausgabe von ps axu --sort:command liefere ich gerne nach, die sprengt hier leider die maximal mögliche Zeichenlänge

Vielleicht hat ja jemand einen Tipp für mich.
Danke.

 

[_Padi]

Gibts bei "ps aux" ein Muster? Falls ja, welches?

 

[shredder01]

Hm, was mir auffällt wäre das es einige Prozesse sehr gehäuft gibt. Z.B. gibt es ca. 300 Eintragungen von /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true, die alle schlafen und ca. 400 von bin/qmail-queue, die auch alle schlafen, außerdem noch ca. 400 Eintragungen wie diese /usr/local/psa/handlers/info/05-grey-Vi8FCg/executable context [email protected] [email protected] (mit allerdings jeweils unterschiedlichen Emailadressen), die alle laufen.
Ansonsten fällt mir hauptsächlich auf das die Anzahl der Prozesse ständig zunimmt, vorhin schrieb ich noch von etwas über 1300 inzwischen sind es über 1600 die mir top anzeigt. Dafür sieht inzwischen der idle-Wert bei top wieder ganz gut aus - zwischen 25 und 35 %.
Dazu muß ich allerdings sagen, das meine bisherige Reaktion immer ein Reboot war, d.h. ich hab es bisher noch nie längere Zeit (über 'ne Stunde) beobachtet, ob das nur vorübergehend ist.

P.S. Heute hab ich den Server das erste Mal "gewähren" lassen und nur beobachtet. Und jetzt nach ca. 2 Stunden laufen die Zugriffe auch ohne Reboot wieder fix, aber die Anzahl der Prozesse steigt trotzdem weiter (inzwischen über 1700, die fast alle als schlafend angezeigt werden). Dafür ist der idle-Wert in top inzwischen bei ca. 40%, was ja ganz gut ist.
Hm, heißt das ich muß mich damit abfinden, das der Server ab und zu mal (vorige Woche war es täglich jeden morgen) für ein bis zwei Stunden schwächelt?

 

[_Padi]

Schau mal hier:

Qmail: Hohe Last durch qmail-smtpd - huschi.net

 

[shredder01]

Ah danke.
Sind schonmal knapp 400 Einträge weniger, mal schauen ob es das auf Dauer war.
Kann ich eigentlich die qmail-queue und qmail-inject (davon gibt es auch eine ganze Latte in der ps-Liste - bin/qmail-inject -a -f DrWEB-DAEMON -- postmaster ) Sachen auch einfach killen?

P.S. Ich hab festgestellt, das seit um 10 Uhr heute nahezu jede Minute ein neuer qmail-queue Prozess im Speicher gelandet ist und dann da geblieben ist.

 

[shredder01]

Hm, inzwischen habe ich über 2700 Prozesse im Speicher laufen, überwiegend /usr/local/psa/handlers/info/05-grey-Vi8FCg/executable, bin/qmail-inject -a -f DrWEB-DAEMON -- postmaster und bin/qmail-queue. Und leider verschwinden auch die neuen /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true Einträge, obwohl ich Anweisungen auf huschi.net befolgt habe, nicht aus dem Speicher.
Kann das alles mit dem hier besprochenen zusammenhängen (da gibt es ja von jemand folgende Meldung:

Das Greylisting zieht mir mittlerweile den kompletten Server runter und startet immer mehr Prozesse mit /usr/local/psa/handlers/info/05-grey-fskV6m/executable

) und wenn ja gibt es dafür eine Lösung?

 

[shredder01]

Hm, da wollte ich schon fast jubeln, weil der Server fast 12 Stunden durchgehalten hat ohne das sich Prozesse gestapelt haben, aber da geht es schon wieder los.
Ab 10:21 Uhr heute bleiben wieder ab und zu bin/qmail-queue, /usr/local/psa/handlers/info/05-grey-Vi8FCg/executable context ..., bin/qmail-inject -a -f DrWEB-DAEMON -- postmaster und /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true im Speicher liegen. Die Logs zeigen zu dieser Zeit kein abweichendes Verhalten. Das einzige was mir in messages auffällt ist, das zu Zeiten wo etwas im Speicher liegengelassen wird die Zeile

call_handlers: stop call handlers from dir '/usr/local/psa/handlers/before-queue/global'

fehlt.
QMail-Prozesse die wieder aus dem Speicher verschwinden haben bei mir einen ähnlichen Ablauf wie diesen:

Jul 18 20:16:11 h1611068 qmail-queue-handlers[25301]: Handlers Filter before-queue for qmail started ...
Jul 18 20:16:11 h1000000 qmail-queue-handlers[25301]: [email protected]
Jul 18 20:16:11 h1000000 qmail-queue-handlers[25301]: [email protected]
Jul 18 20:16:11 h1000000 qmail-queue-handlers[25301]: hook_dir = '/usr/local/psa/handlers/before-queue'
Jul 18 20:16:11 h1000000 qmail-queue-handlers[25301]: recipient[3] = '[email protected]'
Jul 18 20:16:11 h1000000 qmail-queue-handlers[25301]: handlers dir = '/usr/local/psa/handlers/before-queue/recipient/[email protected]'
Jul 18 20:16:11 h1000000 qmail-queue-handlers[25301]: call_handlers: call executable = '/usr/local/psa/handlers/info/05-grey-Vi8FCg/executable'
Jul 18 20:16:11 h1000000 greylisting filter[25302]: Starting greylisting filter...
Jul 18 20:16:11 h1000000 qmail-queue-handlers[25301]: handlers_stderr: DEFER
Jul 18 20:16:11 h1000000 qmail-queue-handlers[25301]: call_handlers: DEFER during call '/usr/local/psa/handlers/info/05-grey-Vi8FCg/executable' handler
Jul 18 20:16:11 h1000000 qmail-queue-handlers[25301]: call_handlers: stop call handlers from dir '/usr/local/psa/handlers/before-queue/global'

Dagegen sieht es bei Prozessen die im Speicher bleiben so aus:

Jul 18 20:23:58 h1000000 qmail-queue-handlers[25459]: Handlers Filter before-queue for qmail started ...
Jul 18 20:23:58 h1000000 qmail-queue-handlers[25461]: Handlers Filter before-queue for qmail started ...
Jul 18 20:23:58 h1000000 qmail-queue-handlers[25458]: [email protected]
Jul 18 20:23:58 h1000000 qmail-queue-handlers[25458]: [email protected]
Jul 18 20:23:58 h1000000 qmail-queue-handlers[25458]: hook_dir = '/usr/local/psa/handlers/before-queue'
Jul 18 20:23:58 h1000000 qmail-queue-handlers[25458]: recipient[3] = '[email protected]'
Jul 18 20:23:58 h1000000 qmail-queue-handlers[25458]: handlers dir = '/usr/local/psa/handlers/before-queue/recipient/[email protected]'
Jul 18 20:23:58 h1000000 qmail-queue-handlers[25458]: call_handlers: call executable = '/usr/local/psa/handlers/info/05-grey-Vi8FCg/executable'
Jul 18 20:23:58 h1000000 greylisting filter[25462]: Starting greylisting filter...

Ich weiß jetzt nicht, ob das den Unterschied macht. Es ist aber das einzig auffällige.
Über einen Großteil der Zeit werden alle QMail-Prozesse brav wieder beeendet, aber dann scheint es plötzlich einen Auslöser zu geben das QMail-Prozesse im Speicher liegen bleiben ... mal mehr mal weniger gehäuft.

Hat jemand eine Idee was da der Grund sein könnte?

P.S. Bei top wird mir z.Z. folgendes angezeigt:

top - 12:08:15 up 23:56, 1 user, load average: 188.06, 181.55, 163.12
Tasks: 895 total, 189 running, 706 sleeping, 0 stopped, 0 zombie
Cpu(s): 4.2%us, 95.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 4044636k total, 1304580k used, 2740056k free, 78772k buffers
Swap: 2104496k total, 0k used, 2104496k free, 387672k cached

Vor allem das idle auf 0% ist und system auf fast 100% macht mir schon Sorgen.

 

[shredder01]

Mal ein kurzer Nachtrag woran es wohl lag (nachdem der Server jetzt wieder inzwischen fast einen Monat problemlos läuft).
Beim durchschauen aller möglichen Logdateien stellte ich fest, das eine auf dem Server gehostete aber zur Zeit inaktive Domain phasenweise Unmengen an Spam zugesandt bekam. An Email-Adressen, die überhaupt nicht existierten. (Vor Jahren lief unter dieser Domain mal ein Email-Dienst)
Und jedes mal sprang das Greylisting an.
Also hab ich die Domain vom Server geworfen. Mit dem Ergebnis das der Speicher nicht mehr von Prozessen "geflutet" wurde.

Meine Interpretation des Ganzen wäre jetzt, das der Server einfach nicht mit dem Abarbeiten der tausenden von Greylisting-Prozessen hinterherkam, weil einfach ständig neue Spammails kamen.