Am Sunday 30 January 2011 schrieb Christian Stubbs:
> Hagen Montag <hagk@hagk.de> writes:
> > Christian Stubbs wrote:
> >> Als kleine Variante vom root-Server gibts noch die vServer. Apache
> >> tauglich mit 1GB ram rund 10EUR. Wenn man weniger ausgeben will und
> >> weniger RAM hat, muss man kräftig am Apache tunen oder auf lighttpd
> >> wechseln. Kommt auch auf die Last an.
> >
> > Dieser Apache muss ja echt schlechte Software sein, wenn der nicht
> > mal auf einem vServer mit 128Mb läuft.
> >
> > Und ich dachte immer, der RAM-verbrauch liegt an den PHP-framworks,
> > den JVM's und Datenbanken, die man so für dynamische websites
> > braucht.
>
> Du hast recht.
>
> Bei Apache landet man halt meistens erstmal bei mpm-prefork mit
> mod-php. Die entsprechenden Pakete werden in den meisten Guides zu
> LAMP empfohlen und ich vermute, dass man die auch installiert kriegt,
> wenn man tasksel benutzt. Und das ist ein Speichermonster, weil für
> jede Connection eine Instanz mit dem ganzen php-Geraffel gebraucht
> wird. Das sind dann locker über 20MB pro Connection.
Wie hast Du das gemessen? Die Ausgaben von ps aux sagen wenig über den
effektiven Speicherverbrauch des Prozesses aus.
> Ich habs oben abgekürzt mit "kräftig tunen". Damit meinte ich, dass man
> das auf mpm-worker mit php über fcgid umstellen kann. Vermutlich ist
> dir die Prozedur aber bekannt.
Okay, meine heftig veraltete Webseite ist wahrscheinlich nicht der Traffic-
Generator schlechthin - obwohl sie laut Google, als ich das letzte Mal
schaute, einen Pagerank von 5 auf der Startseite und einen von 4 auf
übrigen Seiten hatte, aber da ich bislang kein Statistik-Tool eingerichtet
habe... -, aber ich versende auch mpm-prefork und ein bißchen selbst
gebasteltes PHP: Ich komme nicht einmal annäherend in den Bereich, 1 GB
für den Apache zu brauchen.
mondschein:~> free -m
total used free shared buffers cached
Mem: 248 238 10 0 35 104
-/+ buffers/cache: 98 150
Swap: 0 0 0
Das sind 98 - in Worten achtundneunzig - MByte für Apache, Dovecot,
Postfix, Mailman, policyd-weightd... ja, der Wert in der zweiten Zeile in
der Spalte "used" ist der richtige ;). Der Maschine bleibt also noch
bequem viel Platz fürs Caching - das sollte auch so sein! Und das
zusätzlich mit LVM und über 5 logischen Laufwerken, d.h. Ext4-
Dateisystemen.
Es laufen
mondschein:~> ps aux | grep apache | grep www-data | wc -l
10
Apache-Prozesse, die Anfragen beantworten. Was wohl locker reicht, um den
geringen Traffic auf die Seite abzubilden. Apache verwendet diese Prozesse
wieder, er forkt also nicht für jede Verbindungsanfrage einen neuen
Prozess. Das heißt viel interessanter als die Zahl der Zugriffe über einen
gewissen Zeitraum ist die Zahl der *gleichzeitigen* Zugriffe.
Und dann schaue ich mal, ob einer der Apaches wirklich 20 MB verbraucht:
mondschein:~> for P in $(pidof apache2); do pmap -d $P | tail -1 ; done
mapped: 22476K writeable/private: 4820K shared: 568K
mapped: 22764K writeable/private: 5108K shared: 568K
mapped: 22796K writeable/private: 5140K shared: 568K
mapped: 22828K writeable/private: 5172K shared: 568K
mapped: 23088K writeable/private: 5432K shared: 568K
mapped: 23056K writeable/private: 5400K shared: 568K
mapped: 22992K writeable/private: 5336K shared: 568K
mapped: 23080K writeable/private: 5424K shared: 568K
mapped: 22828K writeable/private: 5172K shared: 568K
mapped: 23088K writeable/private: 5432K shared: 568K
mapped: 22344K writeable/private: 4688K shared: 568K
Also kommt mal keiner der Apache-Prozesse auf mehr als gute 5 MB privat
genutzten Adreßraum. Und ob er den wirklich komplett nutzt, ist auch nicht
mal sicher. Den gemeinsamen genutzten Speicher würde ich fairerweise durch
die Anzahl der Prozesse teilen, doch da fängts dann schon an: So eine libc
verwenden auch Postfix, Dovecot, perl mit policy-weightd, Python mit
Mailman und was da sonst noch auf meinem Server vor sich hin werkelt.
Jetzt mal grob hochgerechnet mit den etwa 5 MB pro Apache-Prozesse, könnte
diese Maschine wahrscheinlich noch locker 15 weitere Apache-Prozesse für
insgesamt ca. 75 MB starten, ohne über Gebühr auslagern zu müssen. Das
heißt 25 Benutzer können sich gleichzeitig auf meinem Server austoben,
ohne dass es ein Problem mit der Speicherauslastung gibt. Und wie gesagt,
das alles unter der Annahme, dass jeder dieser Apache-Prozesse die 5 MB
angeforderten Adreßraum auch nutzt.
Also bitte Obacht mit voreiligen Aussagen über den Speicherverbrauch von
Prozessen. Denn diese sind meiner Erfahrung nach fast immer *grob* falsch.
Es braucht schon einiges an Fachwissen und Aufwand, um den
Speichervebrauch eines Prozesses genau zu ermitteln.
Meine Erfahrungswerte sind: Für einen einfachen PHP-Webserver mit etwas
Mail reichen 256 MB mal locker aus. Wie das aussieht, wenn ein Datenbank-
Server ins Spiel kommt und ein mehr oder weniger aufwendiges CMS, ist
nochmal eine andere Sache, aber ich würde mich schwer wundern, wenn mehr
als 384 oder 512 MB erforderlich sind. Es sei denn, Slashdot verlinkt auf
eine URL auf dem Server ;). Bei 512 MB dürften selbst 50-100 gleichzeitige
Anfragen kein Problem darstellen, auch wenn ein einigermaßen gescheites
CMS zum Einsatz kommt.
Und um gezieltes Stellen von mehr Anfragen zu unterbinden, als für
gewöhnliches Surfen erforderlich sind, etwa für Brute Force-Attacken,
gibts auch Möglichkeiten wie mod-evasive oder mod-security.
Zum Schluß empfehle ich folgende kleine Übung für zu Hause:
Führe auf einem frisch gestarteten System, meinetwegen mit twm als Window-
Manager, um nicht viel vorab zu laden, folgende Schritte aus:
- free -m
- iceweasel &
- pmap -d <PID von Iceweasel> | tail -1
- free -m
Vergleiche dann mal den angeforderten Adreßraum mit dem tatsächlichen
Speicherverbrauch und staune! Ein anderer Kandidat dafür: OpenOffice.org,
wahrscheinlich auch LibreOffice.org. Konqueror und andere KDE-Anwendungen
sind hingegen viel genügsamer mit dem Adreßraum. Iceweasel und
OpenOffice.org allozieren indes Adreßraum, als ob es den bei Aldi im
Sonderangebot gäbe - was zumindest für 64-Bit-Systeme ja auch stimmt.
(Jow, da hab ich mich mal wieder provozieren lassen und einen kleinen
inhaltlichen Aspekt aus dem Linux Performance Tuning Kurs, den ich halte,
weitervermittelt.)
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.