RootForum Community

Hallo,

ich ärgere mich schon seit Wochen mit suphp rum.

Ein einfaches, ständiges aktualisieren eines PHP Scripts mit der F5 Taste legt den ganzen Server lahm. Das geht bis 400 Prozesse offen sind und Load weit über 200 geht.

per /etc/security die Prozesse und CPU Zeit zu begrenzen funktioniert nicht, da suphp PAM nicht nutzt.

mod_cband funktioniert nur solange der Server nicht unter Last steht. Unter Last greift mod_cband nicht mehr.

mod_evasive hab ich auch installiert, funktioniert unter Last auch nicht zuverlässig.

Ich hab bereits eine Firma kontaktiert, die damit wirbt dass suphp fast keinen Performanceunterschied zu modPHP hat. Ich hätte für eine saubere suphpInstallation gezahlt, aber die Firma wollte mir dann auch nicht mehr garantieren, das suphp nur minimale Performanceunterschiede zum Modul hat und mein Server nicht mehr abstürzt.

Kurzum: Hier gibt es doch sicher Leute die suphp nutzen.

Was macht Ihr dagegen, dass einer einfach so ne Forkbombe auf eure Systeme loslässt, indem er dauern F5 drückt?

Man muss das doch irgendwie in den Griff bekommen können, dass da nicht unendlich Prozesse gestartet werden die den Server lahmlegen.

Meine Messungen haben ergeben, da suphp ca. 15-20x langsamer ist als modPHP.

....ist suphp für den Praxiseinsatz untauglich?

PS.: Es handelt sich um eine VMware ESX Maschine, 1 CPU, Opteron 2.2 GHZ, 1 GB RAM. Wenn ich der Maschine 2 CPUs gebe und mehr RAM, bringt das auch nichts.

SuPHP (und auch normales CGI) hat den Nachteil, dass bei jedem Aufruf der Interpret komplett geladen werden muss. Bei einem Distributions PHP binary kann das auch mal schnell 10-15 MB sein. Persistent DB Connections, OpCode Caches wie XCache oder APC gehen natürlich auch nicht. In Sachen performance ist SuPHP gegenüber mod_php also sehr deutlich im Nachteil. Das ist ein Fakt und da lässt sich auch nur begrenzt gegensteuern.
Wenn man sowohl auf Sicherheit als auch auf Performance angewiesen ist, sollte man PHP über FastCGI verwenden. Das bietet einen guten Kompromiss.

ms-net wrote:per /etc/security die Prozesse und CPU Zeit zu begrenzen funktioniert nicht, da suphp PAM nicht nutzt.

/etc/limits gibt es auch noch. ;)

Hallo,

ja, ich meinte ja /etc/security/limits

Bei Suse 10.3 steht das dort.

Aber limits funktioniert bei suphp nicht. Limits greift nur bei Usern die PAM nutzen. suphp geht da einfach drüber weg....
Alle Einstellungen unter limits sind für "suphp User" ohne Bedeutung.

Es gibt doch hier sichher massig Leute mit suphp auf dem Server.

Was passiert bei euch wenn Ihr 50x F5 drückt?

ms-net wrote:ja, ich meinte ja /etc/security/limits

Du meintest die /etc/security/limits.conf, ich meine die /etc/limits...

ms-net wrote:Es gibt doch hier sichher massig Leute mit suphp auf dem Server.

Ja, ich zum Beispiel.

ms-net wrote:Was passiert bei euch wenn Ihr 50x F5 drückt?

Nichts besonderes. Die Seite wird geladen.

Tja, unter Suse 10.3 gibt es kein /etc/limits, nur /etc/security/limits.conf

Ich denke mittlerweile, dass es an PHP 5.2.4 liegt.

Wahrscheinlich gibt es mit PHP4 diese Probleme nicht.
PHP5 scheint einen ganz schönen Overhead zu haben.

Generell ist PHP 5.2 deutlich performater als 4.x. Es gibt kaum Situationen, in den es umgekehrt ist.
Ich würde den schwarzen Peter eher deinem Script zuschieben. Klingt blöd, aber verhoff dir von einem PHP downgrade keine Besserung.

Danke für die vielen Antworten!

Ich hab mit Joomla, phpBB, postnuke, typo3, phpnuke, phpinfo, und einigen weiteren PHP Scripts getestet.

Bei allen kann ich den Server innerhalb von einer Minute zum Stillstand bringen, indem ich eine Minute lang F5 ständig antippe.

....ich mach da schon Wochen dran rum.
Ich glaub ich gebs auf.

Oder hat noch jemand einen Tip?

hier hat einer das selbe Problem:
http://www.linuxforen.de/forums/archive ... 95019.html

suphp ist wohl sehr ressourcenhungrig nix....

Schade.

Vielleicht weiß trotzdem jemand ne Lösung.
Im Apachestartscript ulimit zu setzen fällt mir gerade noch ein....


Mal sehen.

Was du suchst ist wie bereits geschrieben FastCGI.

+ suexec