Apache2 hängt sich wegen zuviel RAM in OpenVZ Container auf

[Mordor]

Hallo zusammen,
ich hab hier ein Testsystem mit Debian Squeeze und OpenVZ stehen. In einem Container ist ein Apache2 mit mod_fcgi und PHP installiert. Außerdem läuft noch ein Mysql-Server.

Wenn ich mit ap den Apache beschieße, stürzt dieser immer dann ab, wenn ca. 20 PHP-Prozesse erstellt wurden. In den Logfiles ist dann zu finden, dass der Speicher nicht ausreicht, und einen weiteren Worke-Thread zu erstellen:

[Sat Mar 09 00:53:24 2013] [error] (12)Cannot allocate memory: mod_fcgid: can't run /var/www/testsite/php-fcgi/php-fcgi-starter
[Sat Mar 09 00:53:24 2013] [warn] (12)Cannot allocate memory: mod_fcgid: spawn process /var/www/testsite/php-fcgi/php-fcgi-starter error
[Sat Mar 09 00:53:25 2013] [notice] child pid 1061 exit signal Segmentation fault (11)
[Sat Mar 09 00:53:25 2013] [error] mod_fcgid: fcgid process manager died, restarting the server

Mir ist klar, dass anscheinend die 20 PHP-Prozesse den RAM aufbaruchen. Die Frage die ich mir jetzt stelle ist, ob man die maximale Anzahl an PHP-Prozessen begrenzen kann.
Es gibt zwar eine Direktive für die fcgi.conf, dann hat man aber ein weiteres Problem: hat zum Beispiel der user webseite1 alle 20 PHP Prozesse gestartet, kann der user webseite2 keinen mehr starten. Das wäre also auch nicht gut.

Wie würde man das denn normalerweise lösen?

 

[Mr.Check]

Ich löse dieses Problem seit einiger Zeit mit CloudLinux. Ist ein auf CentOS basierendes System, mit dem du unter anderem die CPU-Zeit und den Arbeitsspeicher pro Systembenutzer (also pro Webhosting) limitieren kannst.

Webhosting nie wieder ohne


EDIT: Habe zu spät gesehen, dass es sich bei deinem Server um einen OpenVZ-Container handelt. Da CloudLinux wie auch OpenVZ seinen eigenen Kernel ins Spiel bringt, funktioniert das in deinem Fall leider nicht. Ich denke, du wirst einfach mehr Arbeitsspeicher an den Start bringen müssen um das Problem zu lösen. Dass einzelne Hostings die Ressourcen des Gesamtsystems auffressen, wirst du so ohne weiteres nicht verhindern können befürchte ich.

 

[Mordor]

So, nach vielem Suchen und Rumtun hab ich rausgefunden, dass wohl eher nicht der Apache und die PHP-Prozesse das Problem sind, sondern eher der OOM-Killer. Werd mich dann mal ein bischen mit der Kmemsize spielen. So kann ich das System besser auslasten.

 

[Bachsau]

Webhosting nie wieder ohne

Man Fragt sich sowieso, wieso es noch immer keinen Server / Plugin gibt, das direkt auf Shared Hosting ausgerichtet ist, und eine saubere Resourcenteilung für alle Bereiche ermöglicht.

 

[Mr.Check]

Man Fragt sich sowieso, wieso es noch immer keinen Server / Plugin gibt, das direkt auf Shared Hosting ausgerichtet ist, und eine saubere Resourcenteilung für alle Bereiche ermöglicht.

Wie meinst du das? Ein (meiner Meinung nach) ideales Betriebssystem für Shared Hosting habe ich ja genannt. Dann noch ein passendes Control Panel draufsatteln und fertig ist die Kiste

 

[d4f]

Man Fragt sich sowieso, wieso es noch immer keinen Server / Plugin gibt, das direkt auf Shared Hosting ausgerichtet ist, und eine saubere Resourcenteilung für alle Bereiche ermöglicht.

Gibt es. Klappt auch wunderbar (sofern du < 2000 Kunden auf einer Büchse hast, bei meinen aktuellen Kundenzahlen schleudert es die Load durch syscalls so unkontrolliert hoch dass das System hängt)

Für Apache und Zubehör:
Das magische System ist sogar im Linux-Kernel drin und nennt sich cgroup.
In Kombination mit mpm_itk, mod_php und mod_cgroup kannst du nach Belieben die Benutzer beschränken.
http://www.mjmwired.net/kernel/Documentation/cgroups

Für MySQL:
Die Google- und Percona-Patches (SHOW USER_STATUS) ermöglichen es schnell Sünder zu finden. Zusammen mit vielen nützlichen Änderungen gibt es das als Paket namens MariaDB ( https://mariadb.org/ ) welches binary-kompatibel zu Mysql ist.


Beachte aber dass -entgegen einigen Lösungen von kommerziellen Anbieter- es KEINE gute Idee ist die aktuell laufenden Verbindungen zu drosseln (dadurch akkumulieren sich nur die vHosts) und auch ein 503 bei kurzfristiger Überlastung ist keine Lösung. Ich konnte zwar die Nebeneffekte teilweise durch entsprechende Programmierung des Reverse-Proxies umgehen - aber halt auch nur teilweise.

 

[Mordor]

@d4f
Das heißt aber, dass man mindestens einen Tod sterben muss, wenn nicht sogar mehrere.
Wie lösen das die gorßen Hoster?

 

[d4f]

Wie lösen das die gorßen Hoster?

Bei ganz Grossen habe ich keinen Einblick hinter die Kulissen aber 0815-Webhoster lösen es indem sie schlicht mehr Hardware verwenden und die vielfressenden Kunden rauswerfen oder auf einer Machine regruppieren =)

Das heißt aber, dass man mindestens einen Tod sterben muss, wenn nicht sogar mehrere.

Wieso? Ich wage zu behaupten dass zumindest die aktuell aktiven Teile bei mir mittlerweile ganz gut laufen =)
Besser laufen würde es wenn Nginx' shared memory-storage ACID wäre und ein paar gleichzeitige "+1 -1" nicht am Ende sowas wie -70 rausgeben würde =)

 

[Marentis]

Ich kenne auch einige Hoster, die bei sehr ressourcenintensiven Kunden empfehlen, dass der Kunde doch bitte ein größeres Paket (oder einen Managed Server) buchen möge. Alternativ wird dann eben nach "fair use" das Vertragsverhältnis beendet, wenn der Kunde auch weiterhin einen großen Teil der Serverresourcen für sich alleine beansprucht.