Server am Limit?

Mein gut 2 Jahre alter von scheint seit einiger Zeit schon auf der Felge zu drehen. Mittlerweile liegt die 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

  • 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 comments

  1. Johny sagt:

    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. :)

  2. Sven sagt:

    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 :)

  3. infogurke sagt:

    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…

  4. Johny sagt:

    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 :/

  5. Johny sagt:

    Habe gerade selbst auf der Seite von Hetzner nachgesehen, also soft-raid.
    Ausserdem, DDR400 RAM ? Ist es diese Konfiguration oder hast du eine andere?

  6. Sven sagt:

    @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.

  7. Sven sagt:

    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

  8. infogurke sagt:

    Braucht jetzt mysqld oder php die CPU-Zeit?

  9. Sven sagt:

    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.

  10. infogurke sagt:

    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.)

  11. Sven sagt:

    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.

  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!

  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 :(

  14. mt sagt:

    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

    :-)

  15. Sven sagt:

    Vielen Dank für die vielen Tipps! Ich bin aktuell immer noch am rumtesten …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.