Unser Server lagged – Zeit für Optimierungen

Ubuntu, Plesk, Apache, PHP, MySQL. Viel mehr läuft auf unserem Server eigentlich nicht. Deutlich potenter als der Vorgänger ist er auch. Warum zum Geier benötigen dann die Webseiten mit einem Mal Sekunden bevor sie angezeigt werden? Zeit wiedermal zu optimieren. Aber wie waren noch gleich die Settings, die ich vor zwei Jahren bei unserem letzten Server verwendet habe? Pff, das passiert mir nicht nochmal, diesmal schreibe ich sie auf!

Apache Optimierung

Beginnen wir beim Apache. Als erstes soll das Apache MPM Modul optimiert werden. Aber welches? Prefork, Worker oder Event?

/usr/sbin/apache2 -l

sagt mir mit welchen Modulen Apache kompiliert wurde. In meinem Fall war es prefork.c, also das Prefork Modul, dass ich nun in der

/etc/apache2/apache2.conf

etwas anpassen kann.

# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_prefork_module>
StartServers      5   #was 1
MinSpareServers   5   #was 1
MaxSpareServers   10  #was 5
MaxClients        150 #was 100
MaxRequestsPerChild   0
</IfModule>

Außerdem sollten alle nicht benötigten Module abgeschaltet werden, die man in

/etc/apache2/mods-enabled

findet. Am besten nutzt man

a2enmod <modulname>

um Module anzuschalten, bzw.

a2dismod <modulname>

um diese abzuschalten. Ich habe z.B. mod_include deaktiviert, da wir keine server Side Includes verwenden.

MySQL

Um überhaupt erstmal einen Zugriff auf die wichtigen MySQL Variablen zu erhalten, musste ich mich als „root“ Nutzer anmelden. Unter Plesk-basierten Systemen gibt es jedoch keinen „root“ Nutzer, sondern nur einen „admin“, der sich ausschließlich von localhost aus anmelden darf. Also rasch lokal mittels

mysql -uadmin -pcat /etc/psa/.psa.shadow

eingelogged und einen neuen User angelegt, mit dem ich dann auch die nötigen Rechte habe, ohne gleich die ganze Zeit als root (bzw. admin) agieren zu müssen:

GRANT ALL PRIVILEGES ON '%'.* to '<username>'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;
CREATE USER '<username>'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

Jetzt kann es aber endlich ans tunen gehen- Haaaaalt das klingt ja so als ob es einfach wäre. MySQL Tuning ist schwieriges Feld und hängt von vielen Faktoren ab, zu denen nicht nur die Serverhardware gehört, sondern auch die Applikationen die darauf laufen, die Tabellenformate (z.B. MyISAM oder innoDB) und folglich auch die Anfragetypen. Man kann also keine „Killer“-Konfiguration posten, die immer optimal läuft. Aber man kann sich mit der Zeit langsam annähern. Beginnen wir mit folgenden Werten in der

/etc/mysqld/my.cnf

im Bereich

[mysqld]

und sehen mal, wie sich die Werte auswirken.

table_open_cache        = 256 #was 64
key_buffer              = 64M #was 16M
read_buffer_size        = 1M  #was 128k
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
query_cache_limit       = 4M
query_cache_size        = 64M

Am besten man liest zu diesem Thema erstmal das High Performance MySQL Buch, treibt sich ein paar Wochen im MySQLPerformance-Blog rum oder liest was ich im Laufe der Monate für semiprofessionelle Ergüsse zu diesem Thema produziere 🙂

To be continued, äh optimized 😉