"Server killt Prozesse!" oder "Schutz vor Ã?be

[dts]

Hallo,

Aus gegebenen Anlasse beschäftige ich mich gerade damit, wie man einen Server vor "Ã?berlast" schützen kann. Der Support konnte mir hierbei nicht wirklich weiterhelfen, deshalb habe ich zu googeln begonnen.

Also werden wir konkreter:

Ich habe einen Rootserver, der (bei extremer Systemlast) ´der Reihe nacht verschiedene Prozesse (auch SSH) killt und natürlich auch nichtmehr startet.

Gibt es eine Möglichkeit dies zu verhindern oder die Systemlast erst gar nicht ins Unermessliche anwachsen zu lassen? Leider habe ich keine guten Ideen gehabt, dieses Problem zu lösen...

Hat jemand von euch Profis bitte ein paar gute Tips auf Lager? :)

Danke und
viele Grüsse

Jürgen

[floschi]

Das Problem ist imho ressourcenbedingt, d.h. zuwenig RAM. Da stellt sich die Frage, was denn diese Last verursacht.

Evtl. lässt sich das Programm/Skript begrenzen...

[dts]

Hallo,

Das Problem sind extreme viele MySQL-Zugriffe, PHP-Skripte und der Apache im Allgemeinen... da es sich um einen Freehostingserver handelt.

Wie könnte man hier für mehr Sicherheit sorgen, hast du eine Idee?

Gruss
Jürgen

[kawfy]

Falls du die Hardware nicht den Anforderungen anpassen kannst, machst du den Sack einfach zu.

• max. Anzahl der Apaches verringern (zähle, wieviele Apaches laufen ("ps x|grep httpd|wc -l") und teile das einfach mal durch 2. 8)
• die max. Anzahl der Verbindungen zur Mysql-DB beschränken. Hier musst du versch. Werte ausprobieren.

Lass mit den neuen Werten den Server einen Tag lang laufen und beobachte die Last. Probiere dann neue Werte. Mache das, bis du einen stabilen Serverbetrieb erreicht hast.

:roll: "Freehostingserver" -- Komisch, es gibt immer noch einen "Markt" für gratis dyn. Webhosting -- dass es User gibt, die das Angebot wahrnehmen, ist klar. Dass es Anbieter gibt, die das aufziehen ist ... "faszinierend". Natürlich nehmen die User mit, was der Server hergibt.

:?: Eine Frage: wie rechnet sich das? (OK, wird offtopic)

[floschi]

gut genutzte Datenbank = hoher Speicherbedarf

Es geht imho nicht ums absichern, sondern ums Tuning ;)

Ich kenne deine Ressourcen immer noch nicht, aber evtl. gibt es die Option, für die Datenbank einen eigenen Server zu spendieren? So läuft das beim rootforum.org/ z.B.

Bei mir hatte ich mit mailman, exim4, mysql, spamassasin und clam-av einen Mailserver mit 96MB RAM versucht zu betreiben -> Dauerswapper und ständig wurde irgend einer dieser Prozesse gekillt, schlimmstenfalls einer der wichtig war -> ungut.

Letztendlich brachte nichts Besserung, weil die Ressourcen einfach zu wenig waren, also bessere Ausstattung in Sachen Hauptspeicher nötig.

[dts]

OKi,

Erstmal danke für eure Antworten. Ich werd mir mal überlegen, wie ich das machen könnte und was es mir tatsächlich wert ist...

Lg
Jürgen

[dts]

Hallo,

Ich habe heute vom Support einen (denke ich) brauchbaren Tip erhalten. Und zwar meinten die, ich könnte doch den grsec-Patch einsetzen, da dieser automatisch Prozesse beendet, die zu stark ausgelastet sind?

Was hält ihr von dieser Idee?
Momantan habe ich:

Code: Select all

Linux hostname 2.4.26-1-386 #1 Tue Aug 24 13:31:19 JST 2004 i686 GNU/Linux

Gruss
Jürgen

[floschi]

Sehr interessante Anmerkung, habe ich in dieser Form noch nie gehört... und vor allem: was soll das bringen? Deine Prozesse werden doch jetzt auch schon beendet, wo ist der Vorteil?

Bekämpfe ruhig die Auswirkungen, ich würde bei den Ursachen ansetzen. Achja, grsec läuft bei mir schon länger.

[captaincrunch]

GRSec macht auch nichts anderes, als effektiv die gesetzten Systemlimits (man ulimit) umzusetzen. Von daher würde ich (erstmal spontan) diese Aussage als Nonsens abtun.

[dts]

Moin,

Ich dachte es mir irgendwie... :evil:
Hmm... naja dann muss ich weitersuchen oder weiss noch jemand was?

Gruss
Jürgen

[alexander newald]

Der 2.4er sollte nicht einfach sinnlos Prozesse abschiessen (ssh zu killen halte ich hier erstmal als sinnlos)

Für nicht root Benutzer ulimit verwenden, für apache und mysql die Anzahl der Prozesse begrenzen. SSH kann man notfalls per cron regelmässig starten (nicht neustarten) lassen und hoffen, dass nicht auch cron gekilled wird.

Was geht denn zu Ende? Speicher / Swap, Filedescriptor? Was steht in den Logs beim killen der/des Prozesses (Auch ein paar Zeilen vorher)?

[dts]

Hallo,

Ich versuche jetzt mal den Apache zu optimieren und habe hier folgende wichtige Zeilen aus der httpd.conf. Läßt sich da für den Betrieb als Freehosting-Server (mit doch sehr vielen Zugriffen) noch etwas optimieren?

Code: Select all

ServerType standalone
ServerRoot /etc/apache
LockFile /var/lock/apache.lock
PidFile /var/run/apache.pid
ScoreBoardFile /var/run/apache.scoreboard
Timeout 150
KeepAlive Off
MaxKeepAliveRequests 10
KeepAliveTimeout 15
MinSpareServers 3
MaxSpareServers 10
StartServers 20
MaxClients 256
MaxRequestsPerChild 100
Include /etc/apache/modules.conf

So, nun zu dem hier:

SSH kann man notfalls per cron regelmässig starten (nicht neustarten) lassen und hoffen, dass nicht auch cron gekilled wird.

Wie soll denn das funktionieren, wenn ich in SSH z.b. eingeloggt bin? Bei einem /etc/init.d/ssh stop und /etc/init.d/ssh start würde ich doch aus der Shell fliegen...?!

Was steht in den Logs beim killen der/des Prozesses (Auch ein paar Zeilen vorher)?

Habe leider letztens die riesengrossen Logfiles gekillt, das bringt mich leider DERZEIT nicht unbedingt weiter. Müßte ich bis zum nächsten Mal (in 1-2 Tagen) warten und dann mal gucken.

Sorry, aber vielleicht hat jemand noch Ideen, die helfen?

Danke und Gruss
Jürgen

[alexander newald]

Zu ssh: Wie ich geschrieben habe (Satz richtig lesen) nicht neustarten, sondern starten!!!! Wenn man /etc/init.d/ssh start macht und SSH läuft, meckert er, dass er sich nicht an den Port binden kann, und es passiert nichts, läuft er nicht, startet er halt.

MaxClients viel weiter runter und mit "ulimit -t 2" die Zeit für die PHP/Cgi Script begrenzen

[captaincrunch]

Der 2.4er sollte nicht einfach sinnlos Prozesse abschiessen (ssh zu killen halte ich hier erstmal als sinnlos)

Als Stichwort: OOM-Killer

[floschi]

a) selbst bei einem ssh restart wird die aktuelle Session nicht gekillt, bestehende Verbindungen bleiben bestehen... wie würdest du sonst je ein ssh-Update machen wollen?

b) leg endlich die Fakten auf den Tisch. Wir (und du auch) stochern total im Nebel, was denn alles möglich sein könnte, wenn es denn zuträfe. Sag wo es hapert (Speicher / Swap, Filedescriptor, wurde ja schon genannt), was diese Probleme hervorruft (wirklich nur der Apache?), was du für Anwendungen auf welchen Ressourcen betriebst (welche Skripte, z.B. ein phpnuke o.ä. auf welcher Hardware, wieviel RAM, wieviel Platte, wieviel Swap, welcher Prozessor, ...).

c) Habe ich langsam das dunkle Gefühl, dass du nicht im Geringsten weisst, von was du redest. Kennst du den Befehl ulimit eigentlich, hasst du überhaupt nachgeschaut, was grsec eigentlich ist? Weisst du, was Linux ist?

[dts]

b) leg endlich die Fakten auf den Tisch.

Hardware:
Celeron 2400 MHz, 512 MB DDR RAM, 80GB HDD

Vermutliches Problem:
Zuwenig Speicher. Ich denke, der Speicher läuft über... :(

Wie schon gesagt läuft darauf ein Freehostingangebot, wo es mir eben auch nicht möglich ist, Skripte (PHP/Perl) zu überarbeiten und eigentlich nur Schutzmechanismen einbauen kann, damit es nicht zu Problem kommt.

Auszug aus meine kern.log:

Dec 12 13:44:05 mail kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Dec 12 13:44:42 mail kernel: VM: killing process spamd
Dec 12 13:44:42 mail kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Dec 12 14:08:50 mail kernel: VM: killing process apache
Dec 12 14:12:22 mail kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0)
Dec 12 14:21:01 mail kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0)
Dec 12 14:21:03 mail kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Dec 12 14:21:04 mail kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Dec 12 14:21:25 mail kernel: VM: killing process httpdtraffik.pl
Dec 12 14:22:25 mail kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Dec 12 14:22:25 mail kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Dec 12 14:22:25 mail kernel: VM: killing process mysqld
Dec 12 14:22:25 mail kernel: __alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
Dec 12 14:22:25 mail kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0)
Dec 12 14:22:25 mail kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Dec 12 14:22:27 mail kernel: VM: killing process apache
Dec 12 14:22:27 mail kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0)
Dec 12 14:22:27 mail kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

Wie man sieht, werden sämtliche Prozesse aus Speichermangel gekillt, oder sehe ich das etwa falsch? Auch "cron" wird gekillt, daher greift auch die Idee nicht, dass ich einfach regelmässig "ssh" starte.

[captaincrunch]

Out of memory sieht IMHO anders aus.

[dts]

Meinst du etwa defekter Speicher?
Der wurde durch den Betreiber bereits getauscht!

Was sollte das denn dann sein?
Google brachte mir mehrere Möglichkeiten... :roll:

[dts]

So, jetzt habe ich mal folgendes versucht:

:arrow: Habe jetzt in der php.info persistente Verbindungen deaktiviert

:arrow: Die httpd.conf wie folgt angepasst:

Code: Select all

Timeout 300
KeepAlive On
KeepAliveTimeout 15
MaxKeepAliveRequests 100
<IfModule prefork.c>
    StartServers         5
    MinSpareServers      5
    MaxSpareServers     10
    MaxClients         150
    MaxRequestsPerChild  0
</IfModule>
<IfModule worker.c>
    StartServers         2
    MaxClients         150
    MinSpareThreads     25
    MaxSpareThreads     75
    ThreadsPerChild     25
    MaxRequestsPerChild  0
</IfModule>

[floschi]

Das obige ist definitiv zuwenig Speicher ;)

Definiere doch mal Freehostingangebot (was läuft dort)... bei der Hardware nehme ich an, du hast einen oder zwei Freunde netterweise mit drauf - alles andere wäre ja sowieso Schwachsinn.

Mehr kann mit den angaben immer noch nicht gesagt werden. Deine Apachespielchen sind ja nett, aber wenn ich nicht mal weiss, was ein Freehosting ist und was da läuft, hilft das herzlich wenig.

[Joe User]

Miete Dir einen zweiten Server (bei Deinem Anbieter ist der RZ-Interne Traffik kostenfrei) und lagere die DB (Query-Cache aktivieren) darauf aus. Gegebenenfalls noch einen dritten Server (Mail) mieten.

BTW: Lege bitte die php.ini/my.cnf/httpd.conf zum Download bereit...

[alexander newald]

Was für ein Kernel verwendest du?

[dts]

Ich verwende den 2.4.26-1-386...
wie schon an anderer Stelle in diesem Thread erwähnt.