Server am Limit?

Autor: Sven

9 Feb 2009

Mein gut 2 Jahre alter Server von Hetzner scheint seit einiger Zeit schon auf der Felge zu drehen. Mittlerweile liegt die Server Last konstant zwischen 1 und 5, zu Stoßzeiten sogar deutlich drüber. Die Benutzer des Arachnophilia Forums bekommen den Leistungseinbruch an betriebsamen Tagen auch schon deutlich zu spüren, und beschweren sich.

Ich habe einige Performance Einstellungen vorgenommen, die allerdings keine sonderliche Verbesserungen brachten. Sowohl am MySQL Server habe ich einige Feintuning Maßnahmen vorgenommen, als auch eAccelerator für PHP installiert. Ebenso habe ich direkt an der vBulletin Software einige Einstellungen vorgenommen, welche die Leistung verbessern sollen. Aber auch das brachte keine Besserung. Vielleicht ist der Server aber auch wirklich am Limit angekommen. Hierzu einige Daten:

Server

Root Server DS 3000 von Hetzner
AMD Athlon 64 3700+
2 GB RAM
2x 160 GB SATA HDD im Hardware RAID 1 Verbund
Debian Etch
Plesk 8.6 Control Panel

Traffic

22 aktive Domains
Geschätzte 120.000 Unique Visits bei weit über 1 Million Seitenaufrufe monatlich
Knapp 200 GB Traffic im Monat
Ca. 90 Datenbankanfragen pro Sekunde

Ist da schon das Limit erreicht bei diesem Server? Sicherlich nimmt das Plesk Control Panel einiges an Ressourcen in Anspruch, allerdings würde ich auch nicht mehr auf dessen Annehmlichkeiten verzichten möchten. Vielleicht ist es wirklich Zeit auf einen neuen, leistungsfähigeren Server umzuziehen. Oder übersehe ich einen Ressourcen-Fresser?

15 Kommentare für "Server am Limit?"

Johny Am 09.02.2009 um 21:03 1
Ich würde unbedingt mal den RAM upgraden auf 8GB. Denke das ist das wichtigste bei 90 Datenbankanfragen pro Sekunde.
Finde übrigens dass es viele visits sind für nur 200GB Traffic im Monat. :)
Sven Am 09.02.2009 um 21:24 2
RAM wurde schon von 1 auf 2 GB aufgerüstet, mehr geht leider nicht bei diesem Server. Swappen tut der Server aber zum Glück (noch) nicht.

Ich habe keine Videos oder sonstige grössere Dateien auf dem Server, deshalb hält sicher der Traffic in Grenzen. Bei Hetzner ist allerdings “nur” 1 TB inklusive, danach wird die Anbindung auf 10 Mbit/s herunter gedrosselt. Also bin ich froh, dass der Traffic so gering ist :)
infogurke Am 09.02.2009 um 23:28 3
Was steht denn bei iowait? MySQL wird die Festplatte wahrscheinlich ziemlich beansprochen.

Ohne mehr zu wissen: MySQL-Anfragen analysieren und dort noch etwas optimieren, die Karre swappt ja noch nciht…
Johny Am 09.02.2009 um 23:52 4
Mehr als 2 GB geht nicht? Hardware-bedingt oder Hetzner-administrationstechnisch-bedingt? :)

Ist Raid ein Soft-Raid oder Hard-raid? und vor allem verlangsamt Raid 1 den Zugriff ja eigentlich auch :/
Johny Am 09.02.2009 um 23:55 5
Habe gerade selbst auf der Seite von Hetzner nachgesehen, also soft-raid.
Ausserdem, DDR400 RAM ? Ist es diese Konfiguration oder hast du eine andere?
Sven Am 10.02.2009 um 08:31 6
@infogurke: iowait müsste ich zu Stosszeiten mal genauer beobachten.

@Johny: Laut Hetzner ist das RAM Upgrade Hardwareseitig auf 2 GB limitiert. Beim Server müsste es das alte Modell mit DDR400 RAM sein.

Es handelt sich zudem um ein Hardware RAID. Kann mal als Option dazu bestellen.
Sven Am 10.02.2009 um 20:42 7
Der iowait ist auch unter Last eigentlich normal. Hier mal das aktuelle Top Resultat:

top - 20:42:15 up 12 days, 9:10, 1 user, load average: 6.46, 6.88, 6.32 Tasks: 187 total, 5 running, 181 sleeping, 0 stopped, 1 zombie Cpu(s): 79.5%us, 13.9%sy, 0.0%ni, 6.3%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2060396k total, 1728952k used, 331444k free, 70552k buffers Swap: 2097140k total, 5560k used, 2091580k free, 1163916k cached
infogurke Am 10.02.2009 um 20:44 8
Braucht jetzt mysqld oder php die CPU-Zeit?
Sven Am 10.02.2009 um 22:48 9
Scheint wohl eher PHP zu sein. Gibt es da eine Möglichkeit genau zu ermitteln welches Programm im Schnitt wie viel CPU in Anspruch nimmt? Stehe derzeit etwas auf dem Schlauch, wie ich die Analyse weiter führen soll.
infogurke Am 10.02.2009 um 23:01 10
Braucht httpd oder php die CPU-Zeit? Oder anders: Nutzt du mod_php oder mod_cgi?

Ich würde dir ganz dringend empfehlen, mod_fcgid einzurichten und jede Domain unter einer eigenen UID ausführen zu lassen. Das verbraucht zwar mehr RAM pro Domain, es wird ja mind. immer ein PHP-Prozess gestartet, hat jedoch wesentliche Vorteile (Sicherheit, Analyse, etc.)
Sven Am 11.02.2009 um 07:41 11
PHP braucht die CPU Zeit.

PHP läuft auch bereits als mod_fcgi. Ausserdem ist suPHP installiert, so dass PHP unter der UID der jeweiligen Domain ausgeführt wird.
Alain Fontaine Am 11.02.2009 um 22:37 12
Hallo,

Ich schau gerne mal “in den Server rein” wenn du mir Zugriff gibst. Ein eigener Account mit vollen “sudo” Rechten wäre gut :-)

Einige Ideen die mir gerade so durch den Kopf gehen :

- einen kleinen zweiten Server mieten und squid als reverse proxy für deine “hungrigsten” Websites einrichten. Der “application Server” (Apache) kriegt somit sehr deutlich weniger Arbeit mit statischem Content (Bilder etc). Eine minimal Maschine mit Debian, 512MB RAM und 80GB Disk reichen da völlig, mit der kleinsten CPU die du kriegen kannst. Squid ist sehr optimiert :) [für einen temporären Test stelle ich gerne eine Maschine zur Verfügung]

- oder aber Squid auf die gleiche Maschine setzen, was allerdings wesentlich mehr Umkonfigurieren heisst, also Risiko und downtime.

- Phase 2 : PHP code so optimieren dass der zutreffende Output auch vom squid gecached werden kann : ETag caching, etc.

- mit dem Zend Profiler deinen Code mal durchlaufen lassen und die Ressource-fressenden Teile optimieren

- SQL query caching (mit Cache_Lite oder ähnlich) einrichten um MySQL zu schonen. Da dein Problem aber nicht MySQL zu sein scheint, bringt dies so direkt wahrscheinlich nicht viel.

- für Apache die MaxClients, MinSpareServers, MaxSpareServers etc anpassen

- idem : KeepAlive timeout runtersetzen (2-3 Sekunden sollten reichen, mit ‘nem Squid davor kannste sogar komplett ausschalten)

- eAccelerator Konfiguration tunen (Speicher etc.)

Noch ein Tip zur Sicherheit: die PHP Extension SUHOSIN leistet da Gutes!
Alain Fontaine Am 11.02.2009 um 22:49 13
Noch was – was sagt denn der Apache server-status? Kann ja auch einfach sein dass die connection queue überläuft weil nicht genügend Apache Serverprozesse verfügbar sind. Das wäre dann leicht verbessert indem du einfach die MaxClients hochschraubst. Aber Achtung : je mehr Prozesse, je mehr Speicher wird genutzt, und wenn’s dann mit Swappen anfängt, ist Ende :(
mt Am 25.03.2009 um 02:01 14
bin über google hier gelandet:

wenn es noch aktuell ist – die kiste sollte das locker wegstecken – plesk macht es mit der konfiguration manchmal etwas schwer.

suphp ist soweit ich weiß nicht mit fastcgi zu machen. fastcgi macht einen riesen unterschied. suphp selbst braucht man auch nicht. allerdings ist es mit plesk bis 8.6 soweit ich weiß nicht möglich php per default als fastcgi laufen zu lassen.

also umbedingt checken ob php wirklich per fastcgi läuft, weil suphp normalerweise für jeden request eine php instanz startet und das ist extrem langsam.

dann apache mpm_worker installieren das geht nur mit php wenn es als fastcgi läuft, unnötige apache module raushauen und entsprechend konfigurieren. hat den vorteil das alle statistischen files relativ fix rausgehauen werden da nur ein neuer thread erzeugt werden muss, was nur ein bruchteil der funktionalität benötigt. falls noch mod_php herumschwirrt ebenfalls raushauen, das macht fastcgi.

anderes problem könnte sein, dass ständig php prozesse erzeugt werden. da muss man ein wenig schauen wie es so durchschnittlich aussieht und dann entsprechend gleich beim server start die php binaries starten.

für mysql kann ich nur http://mysqltuner.com empfehlen. vorallem query_cache und thread_cache bringen wohl ne menge. bei den speicher angaben sollte man sich aber nicht umbedingt daran halten. eher weniger.

ansonsten ist der apc cache ganz brauchbar. der frisst nur einmal speicher und teilt den für alle php-fastcgi prozesse.

falls das nicht fruchtet eventuell mal ngix anschauen http://nginx.net/ – und per mod_proxy anfragen darüber laufen lassen für vbulletin und so sollte es auch rewrite regeln geben. ansonsten ist der tipp mit squid ganz brauchbar – der kann auch auf dem selben rechner laufen – squid braucht allerdings ram.

zu plesk – wenn es nur von dir genutzt wird kannst du es auch auf 1 prozess beschränken oder die oberfläche stoppen und halt bei bedarf starten.

vbulletin kann auch cachen – da weiß das forum bestimmt mehr.

ansonsten ein aktuelles php5 wirkt auch wunder (http://sebastian-bergmann.de/archives/634-PHP-GCC-ICC-Benchmark.html)

ich hab testweise den benchmark mal mit der beta von php 5.3 laufen lassen und die geschwindigkeit hat sich verdoppelt – wäre eventuell auch eine variante

kann man gefahrlos mit ngix und php 5.3 auf einem anderen port testen.

die kiste sollte das locker wegstecken

:-)
Sven Am 25.03.2009 um 07:41 15
Vielen Dank für die vielen Tipps! Ich bin aktuell immer noch am rumtesten …