FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Apache, Lighttpd, nginx, Cherokee
hasch
Posts: 99
Joined: 2007-03-09 15:23

FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by hasch » 2007-05-23 22:56

Mir ist aufgefallen, dass pro Vhost (mit suexec) ein PHP-Binary im Ram vorgehalten wird, ist dies bei FastCGI normal oder nur durch suexec bedingt? Gibt dafür sicherlich keine Abhilfe, diese im Ram zu minimieren, außer das "frühzeitigere" killen des jeweiligen FCGI-Prozesses!? :)

Roger Wilco
Administrator
Administrator
Posts: 5924
Joined: 2004-05-23 12:53

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by Roger Wilco » 2007-05-23 23:01

Das ist zum größten Teil durch SuExec bedingt. Für jeden Benutzer muss die von die eingestellte Anzahl von PHP-Prozessen vorgehalten werden. Ohne SuExec könnten (müssten aber nicht) X Prozesse für alle VirtualHosts gemeinsam vorgehalten werden.

Du brauchst dich allerdings nicht sonderlich darum sorgen. Wo möglich wird der Code im Speicher geteilt, d. h. es wird für X PHP-Prozesse nicht X mal die Speichermenge eines einzelnen PHP-Prozesses benötigt. Vielleicht willst du ja mal mit pmap herumspielen.

hasch
Posts: 99
Joined: 2007-03-09 15:23

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by hasch » 2007-05-23 23:42

Danke für deinen Hinweis, tolles Tool pmap. Nunja aber auch pmap zeigt mir für jeden FCGI-Prozess von einem anderen Suexec-User die vollen 20MB PHP-Anwendung an, d.h. dies ist nicht mehr zu reduzieren oder teilen sich auch verschiedene Suexec-FCGI-Prozesse den Code im Speicher?

kase
Posts: 1031
Joined: 2002-10-14 22:56

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by kase » 2007-05-24 13:58

Benutze mod_fcgid anstatt mod_fastcgi, da mod_fcgid die PHP-Prozesse erst spawnt, wenn ein Benutzer auf eine PHP-Datei zugreift. Wenn du mehrere vHosts hast, die gar kein PHP verwenden, dann hast du auch keine PHP-FCGI Prozesse für diese User.

Außerdem kannst du bei mod_fcgid (und PHP >= 5.2.0) PHP_FCGI_CHILDREN = 0 setzen, dann wird auch immer nur 1 Prozess gespawnt (bei sehr vielen Requests natürlich entsprechend mehr).

hasch
Posts: 99
Joined: 2007-03-09 15:23

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by hasch » 2007-05-24 15:08

Ich nutze mod_fcgid. Vllt. hab ich mich falsch ausgedrückt, es geht darum, dass pro VHost jeweils ein PHP vorgehalten wird (natürlich wird das nach einer gewissen Zeit wieder gelöscht, bleibt aber eben bsw. 7200 Sekunden im Speicher):
5219 vhost1 18 0 19864 7848 4712 S 0 0.4 0:00.08 php
5221 vhost2 15 0 19876 8436 5200 S 0 0.4 0:00.26 php
Und um diese ca. 20MB pro VHost im Speicher gehts, die diesen ja reichlich füllen und da war meine Frage, ob man dies minimieren kann.

kase
Posts: 1031
Joined: 2002-10-14 22:56

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by kase » 2007-05-24 15:33

Das ist ja der Sinn von FastCGI, genau deswegen bleiben die Prozesse im Speicher. Wenn du willst, dass nach jedem PHP-Request der PHP-Prozess wieder beendet wird, schaue dir mod_suphp in Verbindung mit php-cgi an.

Bei vielen Requests geht dir dort aber sehr viel Performance verloren, eben weil die PHP-Prozesse immer und immer wieder gestartet und beendet werden müssen.

dotme
Posts: 150
Joined: 2004-12-15 16:48

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by dotme » 2007-05-24 15:34

Bei mod_fcgid könntest Du mit "IdleTimeout" und "IdleScanInterval" herumspielen.

hasch
Posts: 99
Joined: 2007-03-09 15:23

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by hasch » 2007-05-24 15:35

Ja es soll ja PHP auch im Speicher bleiben, eben nur nicht für jeden VHost, d.h. ein gemeinsames PHP im Speicher wäre ja ideal, aber dies ist wohl dank suexec nicht möglich... :)

kase
Posts: 1031
Joined: 2002-10-14 22:56

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by kase » 2007-05-24 15:58

Achso, jetzt verstehe ich, was du meinst :)

Und ja, das ganze ist Möglich, da mod_fcgid auch PHP-Prozess-Sharing (den Ausdruck habe ich gerade mal so erfunden *ggg*) kann.

Vorraussetzung dafür ist, dass jeder vHost:

- den gleichen SuexecUserGroup hat
- den gleichen php-fcgi-wrapper bzw das gleiche php-binary
- die gleiche php-Endung

Beispiel:

Du hast 5 verschiedene vHosts von 5 verschiedenen Users.

Alle vHosts haben als SuexecUserGroup userOhneRechte:userOhneRechte

Alle vHosts haben als FCGIWrapper /var/www/php-wrapper-scripts/userOhneRechte/userOhneRechte

Alle vHosts haben die PHP-Endung .php

mod_fcgid startet in diesem Fall keine 5 PHP-Binarys in den Speicher (für jeden vHost), sondern startet nur eins, auf das alle 5 vHosts Zugriff haben.

hasch
Posts: 99
Joined: 2007-03-09 15:23

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by hasch » 2007-05-24 16:12

Ja danke das ist klar, es war ja nach einer Möglichkeit gesucht mit verschiedenen Suexec Usern dies zu ermöglichen, was nun aber scheinbar nicht geht...

D.h. VHost1 -> user1:gruppe
VHost2 -> user2:gruppe

Und da suexec ein eigenen Wrapper für jeden VHost fordert, ist dies nicht machbar... :)

kase
Posts: 1031
Joined: 2002-10-14 22:56

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by kase » 2007-05-24 16:13

Das ist aber allein deswegen schon nicht machbar, weil 1 Prozess nicht 2 Usern gehören kann :)

oxygen
Posts: 2138
Joined: 2002-12-15 00:10
Location: Bergheim

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by oxygen » 2007-05-24 20:10

hasch wrote:

Code: Select all

5219 vhost1  18   0 19864 7848 4712 S    0  0.4   0:00.08 php
5221 vhost2  15   0 19876 8436 5200 S    0  0.4   0:00.26 php
Und um diese ca. 20MB pro VHost im Speicher gehts, die diesen ja reichlich füllen und da war meine Frage, ob man dies minimieren kann.
Das sind nicht 20 MB, sondern nur 3 bzw. 3,2 MB. Speicherverbrauch = RES - SHR. Es schadet nicht, wenn man sich über die Bedeutung der Abkürzungen wie VSZ, RSS (ps) RES, SHR, SWP, VIRT (top) im klaren ist.

dtdesign
Posts: 391
Joined: 2006-09-05 21:12
Location: Berlin

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by dtdesign » 2007-05-24 20:45

Kleine Anmerkung:

Da ich gerade selber nicht wusste, wofür die Abkürzungen stehen, ein "man top" hilft (unter Debian) weiter ;)

Gruß
dtdesign

hasch
Posts: 99
Joined: 2007-03-09 15:23

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by hasch » 2007-05-24 21:42

Vielen herzlichen Dank, dann ist das Problem ja halb (ok eigentl. 7-fach) so groß (klein)... :)

blattlaus
Posts: 52
Joined: 2007-03-08 13:45

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by blattlaus » 2007-05-25 09:53

oxygen wrote:
hasch wrote:

Code: Select all

5219 vhost1  18   0 19864 7848 4712 S    0  0.4   0:00.08 php
5221 vhost2  15   0 19876 8436 5200 S    0  0.4   0:00.26 php
Und um diese ca. 20MB pro VHost im Speicher gehts, die diesen ja reichlich füllen und da war meine Frage, ob man dies minimieren kann.
Das sind nicht 20 MB, sondern nur 3 bzw. 3,2 MB. Speicherverbrauch = RES - SHR. Es schadet nicht, wenn man sich über die Bedeutung der Abkürzungen wie VSZ, RSS (ps) RES, SHR, SWP, VIRT (top) im klaren ist.
Anmerkung: SHR gibt an, wieviel Speicher geshared werden könnte und nicht wieviel geshared wird. Ich weiß nicht, wie weit der Kernel zulässt, dass sich zwei Prozesse von unterschiedlichen Usern Speicherbereiche teilen.

kase
Posts: 1031
Joined: 2002-10-14 22:56

Re: FastCGI PHP-Binary für jeden Suexec-VHost im Ram

Post by kase » 2007-05-25 20:01

Ich bin mir inzwischen auch gar nicht mehr sicher, was VIRT überhaupt ist. Früher bin ich immer nach RES gegangen, und dachte, das wäre der eigentliche Speicherverbrauch.

Bei meinem vServer ist es aber so, dass der RAM immer nach dem vollen VIRT Wert berechnet wird.

Beispiel:

Ich habe 100k privvmpages a 4 KB.

Nun starte ich ein Programm, das 100 MB VIRT, 30 MB RES und 5 MB SHR verbraucht.

Danach habe ich 100k - (100 MB VIRT / 4 KB) privvmpages weniger, und zwar ganz exakt, und eben nicht 30 MB RES / 4 KB.

Finde das auch etwas merkwürdig, aber es war bisher bei jedem vServer so.

Wenn das ganze auch für "echte" Server gilt, dann muss man wohl doch eher nach VIRT gehen und nicht nach RES.