Neuer vServer: Etch oder Lenny? Apache oder lighthttp?

[dev]

Hi,

ich brauche für ein Projekt einen neuen vServer. Es geht um eine PHP/MySQL Geschichte, PHP wird als fast-cgi eingebunden.

Ich habe Erfahrungen mit einem 256 MB vServer, auf dem unter Etch der Apache/MySQL und Postfix ihren Dienst verrichten. Bei der Kiste bin ich bei einem durchschnittlichen RAM Verbrauch von 400 MB (bei optimierter Konfiguration für den Web- und SQL-Server) dabei. Ich habe das Projekt testweise mal installiert - rennt ganz gut, wenn es viele Reloads/Requests gibt, streckt der Apache die Hufen mit 'nem 500er wegen Speichermangel.

Ich frage mich also, wie ich das Ding am besten konfiguriere. Den vServer würde ich mit 512 MB zugesichertem RAM ordern:

1. Wie sieht es mit dem Speicherbedarf von Etch vs. Lenny bei gleicher Grundkonfiguration aus?
2. Macht das Wechseln von Apache -> Lighthttp diesbezüglich Sinn?

Der Distriwechsel nach dem Aufsetzen hält sich ja aufwandstechnisch in Grenzen (Hosteurope bietet im Moment nur Debian 4 Images für die vServer).

Wenn ich auf den lighthttp setze, muss ich alles neu lernen (Konfig, Tuning) - lohnt sich das?

Danke

 

[Roger Wilco]

1. Wie sieht es mit dem Speicherbedarf von Etch vs. Lenny bei gleicher Grundkonfiguration aus?

Dürfte bei gleichen laufenden Diensten identisch sein.

2. Macht das Wechseln von Apache -> Lighthttp diesbezüglich Sinn?

Ich glaube nicht, dass dein Apache httpd Grund für die hohe Speicherbelegung ist und falls doch, lässt er sich durchaus noch etwas zurecht stutzen.

 

[dev]

Findest Du, dass 400 MB zu viel sind? Aber mir fällt gerade ein: Da läuft ja auch noch Munin als Master.

Mein monit sagt das über den Apachen:

Memory usage 0.1% [6068kB]
Children 9
Total CPU usage (incl. children) 0.0%
Total memory usage (incl. children) 2.6% [105756kB]

103 MB für den Apachen, also ca. 11 MB pro Prozess. Ist das viel für den mpm-worker?

 

[foobar99]

Das sollte sich noch deutlich drücken lassen, die Anzahl der Children ist z.B. viel zu hoch (1-2 wären sinnvoll). Bei so wenig RAM würde ich aber einfach auf Lighttpd umsteigen, damit wäre der Speicherbedarf im einstelligen MB-Bereich, Tuning braucht man überhaupt nicht.

 

[Roger Wilco]

Das sollte sich noch deutlich drücken lassen, die Anzahl der Children ist z.B. viel zu hoch (1-2 wären sinnvoll).

Pauschal? Bestimmt nicht. Wenn so viele Verbindungen da sind, dass diese Anzahl Kindprozesse benötigt werden (immer beachten, Worker ist ein Multiprozess/Multithread-Modell), kann die Anzahl nicht einfach reduziert werden. Ich würde eher bei den im Apache httpd eingebundenen Modulen ansetzen.

Bei so wenig RAM würde ich aber einfach auf Lighttpd umsteigen, damit wäre der Speicherbedarf im einstelligen MB-Bereich, Tuning braucht man überhaupt nicht.

Wieder zu pauschal und du vergisst den Speicher, den die PHP-Prozesse verbrauchen werden. Der lighttpd hat in letzter Zeit bei der Entwicklung nicht unbedingt geglänzt. Alternativen wie Cherokee oder nginx gewinnen dadurch eher an Attraktivität. Vor allem ersteren fand ich ganz schick, wobei nginx einfach ein Arbeitstier ist, das ziemlich schwer kaputt zu bekommen ist.

 

[dev]

Die Module sind wie schon gesagt auf ein Minimum reduziert, da geht nichts mehr.

Die apache2.conf sieht an den neuralgischen Stellen so aus:

Timeout 300
KeepAlive On
MaxKeepAliveRequests 10
KeepAliveTimeout 2

<IfModule mpm_worker_module>
    StartServers         1
    MinSpareThreads      5
    MaxSpareThreads      10
    MaxClients           30
    ThreadsPerChild      15
    MaxRequestsPerChild  1000
</IfModule>

Mit diesen veränderten Einstellungen habe ich knapp 200 MB rausgeholt, die Kiste lief vorher mit ca. 600 MB Verbrauch (256 fest, bis 800 wenn verfügbar).

Ich dachte/denke, dass da nicht mehr viel Optimierungspotenzial ist?!

 

[Mordor]

Wenn ich das jetzt richtig interpretiere, hast du dir zwei Drittel von den zur Verfügung stehenden Apacheresourcen genommen. Was ich ich da gerade frage ist, ob das für dein Projekt noch reicht?

 

[dev]

Morder, ich kann Dir gerade nicht folgen? Gib mir einen Tip, was Du mit den 2/3 meinst?

 

[Mordor]

Ich glaub das war jetzt mein Fehler. Ich hab Childs mit Threads verwechselt.
Ich dacht vorher, dass du 3 Threads am laufen hattest.

Aber mal rein Interesse halber:
Was hast du jetzt eigentlich geändert?

 

[dev]

Diese Debian 4 Apache 2 Defaults

Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15

<IfModule mpm_worker_module>
    StartServers          2
    MaxClients          150
    MinSpareThreads      25
    MaxSpareThreads      75 
    ThreadsPerChild      25
    MaxRequestsPerChild   0
</IfModule>

habe ich in das geändert:

Timeout 300
KeepAlive On
MaxKeepAliveRequests 10
KeepAliveTimeout 2

<IfModule mpm_worker_module>
    StartServers         1
    MaxClients           30
    MinSpareThreads      5
    MaxSpareThreads      10
    ThreadsPerChild      15
    MaxRequestsPerChild  1000
</IfModule>

Dazu habe ich alle Module rausgeschmissen, die ich nicht brauche. Das hat 200 MB gebracht.

Die RAM Last war 600 MB unoptimiert und beträgt seit den Änderungen nur noch 400 MB. Der Server ist ein vServer mit 256 MB garantiertem RAM und bis zu 800 MB dynamisch.

Jetzt brauche ich für ein Projekt einen 2. vServer und würde einen mit 512 MB garantiertem RAM bestellen.

Und das wäre auch ein guter Zeitpunkt, um wieder etwas an der Konfig zu schrauben, da das neue Projekt sich etwas mehr RAM genehmigt (hab es testweise auf der 256 MB Kiste laufen lassen).

 

[floogy]

Ich bin auf einem vserver noch wesentlich eingeschränkter in den Ressourcen, und habe deshalb auf den lighttpd umgestellt, als nach dem upgrade auf lenny nichts mehr lief, weil privvmpages und numfiles ständig überschritten waren.

Das lag wohl hauptsächlich an der Umstellung apache 1.3.x auf apache 2.x.
Trotz der extremen Drosselung des Apache kam ich mit den Ressourcen nicht hin. Das Problem ist gallery2 und Typo3, für die ich InnoDB verwende. Das schlägt mit >100MB zu Buche.

Jetzt frage ich mich, ob man die php5-cgi noch schlanker machen kann?
Ich muss vor jedem aptitude full-upgrade erst einmal den lighty beenden.

Die Top10 Prozesse (Anzahl, Prozessname, PID):

# lsof +c 15 | awk '{printf("%15s  (%s)\n", $1, $2)}' | sort | uniq -c | sort -rn | head
    127        php5-cgi  (30307)
    119          master  (24216)
    112        php5-cgi  (30282)
     59        lighttpd  (30280)
     43            sshd  (29951)
     39            sshd  (29820)
     39          mysqld  (27966)
     32            smtp  (29909)
     32           local  (29907)
     30            sshd  (3591)

# egrep '(uid|lockedp|privvm|numfile)' /proc/user_beancounters 
       uid  resource           held    maxheld    barrier      limit    failcnt
            lockedpages           0          0        344        344        248
            privvmpages       53215      53238      65536      67072     270043
            numfile            1490       1490       2500       2500      39521

# bin/vzfree 
VPS Speichernutzung:
Momentan genutzt:       208,219 MB
Zugesichert:            96 MB
Maximal nutzbar:        262 MB

fastcgi.server = ( ".php" => (( 
                     "bin-path" => "/usr/bin/php5-cgi",
                     "socket" => "/tmp/php.socket",
                     "max-procs" => 1,
                     "bin-environment" => ( 
                # "PHP_FCGI_CHILDREN" => "16",
                       "PHP_FCGI_CHILDREN" => "1",
                       "PHP_FCGI_MAX_REQUESTS" => "10000" 
                     ),
                     "bin-copy-environment" => (
                       "PATH", "SHELL", "USER" 
                     ),
                     "broken-scriptfilename" => "enable" 
                 )))

Ich denke, das ist alles schon so zurechtgestutzt, die Antwortzeiten würden inakzeptabel werden (sind es wohl schon bei mehreren Benutzern).

Jedenfalls steht ein Wechsel des Angebots an.

 

[Roger Wilco]

Das Problem ist gallery2 und Typo3, für die ich InnoDB verwende.

Ändere die Tabellen-Engine auf MyISAM und deaktiviere die InnoDB-Unterstützung in deiner my.cnf.

Jetzt frage ich mich, ob man die php5-cgi noch schlanker machen kann?

Ja, allerdings nicht mit den distributionseigenen Paketen. Grundsätzlich könntest du aus der php.ini aber alle Module rauswerfen, die du nicht benötigst.

Und mal ehrlich: Mit 96 MB Hauptspeicher zu versuchen, ein sinnvolles Setup inkl. Webserver und Datenbankserver (und vermutlich nocht Mailserver...) herzustellen, ist lächerlich.

 

[floogy]

Und mal ehrlich: Mit 96 MB Hauptspeicher zu versuchen, ein sinnvolles Setup inkl. Webserver und Datenbankserver (und vermutlich nocht Mailserver...) herzustellen, ist lächerlich.

Da gebe ich Dir recht. Ich werde demnächst auch umsatteln. Danke für die Tipps.

Ohne InnoDB sind einige Wartungstools gallery2s nicht mehr funktionsfähig da Transaktionen und damit refferentielle Integrität und automatische Datenwiederherstellung fehlen.
Gallery2:MySQL - Gallery Codex

Aber in meinem Fall wird das wohl die Nachteile durch den höheren Speicherverbrauch nicht aufwiegen...

 

[foobar99]

Pauschal? Bestimmt nicht. Wenn so viele Verbindungen da sind, dass diese Anzahl Kindprozesse benötigt werden (immer beachten, Worker ist ein Multiprozess/Multithread-Modell), kann die Anzahl nicht einfach reduziert werden.

Eben, worker verwendet Threads, da braucht man nicht so viele Prozesse. Viel mehr als 100 Verbindungen macht ja auf so einem Server eh keinen Sinn.

Wieder zu pauschal und du vergisst den Speicher, den die PHP-Prozesse verbrauchen werden.

Das ist wieder was anderes, er verwendet doch schon FastCGI.

 

[dev]

So, ich habe erste Ergebnisse, habe den Server heute bestellt und 1 Stunde später war der online.

VPS: HE Virtual Server Linux XL 3.0 mit 512 MB zugesichertem RAM (bis 1024 dyn.)
Tool: vzfree

Etch: Debian 4.0 mit sshd ohne weitere Dienste nach dem Booten (HE Image)
Lenny: Debian 5.0 mit sshd ohne weitere Dienste nach dem Booten (HE Image -> dist-upgrade)

Momentan genutzt: 24,1562 MB
Maximal genutzt: 24,1562 MB
Zugesichert: 512 MB
Maximal nutzbar: 1050 MB

Danach habe ich ein dist-upgrade gemacht und wieder gemessen:

Momentan genutzt: 11,2891 MB
Maximal genutzt: 11,2891 MB
Zugesichert: 512 MB
Maximal nutzbar: 1050 MB

Der RAM Verbrauch spricht also nicht gegen Lenny. Komischerweise war nach einem ersten Start des Default-Apachen der Speicher zu 600 MB belegt. Erst durch Reduktion der MaxClients etc. wurde es besser.

Daneben habe ich mich den ganzen Tag mit dem Apachetuning beschäftigt, aber ich checke diese bekloppte Nomenklatur StartSpareFucki****** Dingenskirchen nicht und kann die Zusammenhänge zwischen der Konfig und top/ps auxf nicht 100% verstehen.

Da mache ich jetzt weiter...

 

[XioniX]

Komischerweise war nach einem ersten Start des Default-Apachen der Speicher zu 600 MB belegt.

Muss es unbedingt das Worker-MPM sein? Da du wohl eh nur einen Prozessorkern bei einem Vserver zur Verfügung hast und das Speichermanagement dort nicht gerade das optimalste ist, lohnt das überhaupt nicht. Nimm Prefork und freu dich am vielen freien Speicher PHP kannst du ja immer noch per CGI einbinden.

 

[dev]

Hmm. So weit ich das in den letzten Monaten verstanden habe, ist gerade der Worker für Schmalspurspeicherrechner besser geeignet, da die Threads wesentlich weniger Speicher verbrauchen als die geforkten Instanzen - gerade wenn es in den Hochlastbetrieb geht.

Ausserdem sprechen weitere (persönliche) Gründe dafür:

1. ist es bzgl. des Aufwands egal, ob ich den prefork oder worker optimiere
2. habe ich ausschliesslich Erfahrung mit dem worker/suexec und php als fcgid

Mit dem prefork habe ich noch nicht gearbeitet und da der worker seit Monaten auf mehreren Maschinen zuverlässig seinen Dienst verrichtet, sehe ich keine Veranlassung, hier etwas zu ändern

Am Rande: Mittlerweile läuft eine leere Drupalinstallation auf der Kiste und das System fühlt sich sehr 'snappy'. Mit einem User (mir ) bin ich bei 360 MB RAM Auslastung. Einen Unterschied in der Response zu einem dedizierten Rechner kann ich nicht 'erfühlen'. Ich werde jetzt mal den eAccelerator drauftun und morgen muss ich die my.cnf noch tunen.

Auf jeden Fall bin ich mit der derzeitigen Performance mehr als zufrieden. Der Host ist ein

model name : Intel(R) Xeon(R) CPU 3050 @ 2.13GHz
stepping : 6
cpu MHz : 1066.722
cache size : 2048 KB

Für brutto knapp 20 EUR ist dieser vServer echt gut. Mein kleineres Modell bei HE ist träger (mit einem 3.4 Ghz P4 als Host).