Severdienste Apache, Postfix, Oracle/MySQL und Samba optimieren

Serveroptimierung ist eine Überlebensfrage: Ab einer bestimmten Last sinkt seine Effizienz. Setzen ihn weitere Anfragen noch mehr unter Druck, bricht das System zusammen. Um den Ausfall eines unternehmenskritischen Dienstes zu verhindern, heißt es, vorsorgen, solange noch Zeit ist. Nicht immer ist schnellere Hardware die richtige Lösung. Auch eine optimale Konfiguration des Serversystems und der darauf laufenden Dienste kann Wunder wirken. Fünf Profis verraten, was Systemadministratoren unbedingt tun oder lieber lassen sollten, um den Datendurchsatz auf ihrem Web-, Mail-, Datenbank- oder Samba-Server so hoch wie möglich zu halten.

Eine gesunde Basis

Unabhängig vom Servertyp gibt es ein paar Grundregeln, die jeder Systemadministrator beachten sollte. Ralf Spenneberg, Buchautor und Dozent zum Thema Linux-Systemadministration, rät, für eine optimale Performanz Folgendes zu beherzigen.

1. Du sollt auf die Mischung achten! Für jeden Dienst gibt es mindestens einen Faktor, der die Performanz bestimmt: CPU, I/O, oder Speicherverbrauch. Daher ist es sinnvoll, die Dienste so zu verteilen, dass auf derselben Maschine möglichst nicht zwei Dienste laufen, die auch denselben Performanz-bestimmenden Faktor haben (Abbildung 1).

Abbildung 1: Eckige Keile in runde Löcher: Möglichst unterschiedliche Anforderungen zweier Dienste hinsichtlich CPU-Zeit, Speicher und I/O lasten einen Server besser aus als konkurrierende Anforderungen.

Ein Mailserver ist zum Beispiel meist durch die Platten- und Netzwerk-Latenz in seiner Geschwindigkeit begrenzt. Falls nicht ein integrierter Virenscanner zusätzlich Prozessorzeit beansprucht, hat die CPU auf einem für die Postverteilung zuständigen Server genug Zeit, um andere Aufgaben zu erledigen.

2. Du sollt überwachen! Nur durch genaue und langfristige Beobachtung lässt sich feststellen, welches die Performanz-bestimmenden Faktoren sind und in welchem Rahmen sich die Werte für CPU, I/O oder Speicherverbrauch im Normalbetrieb bewegen. »vmstat« und »sar«-Diskfunktion analysieren den Plattendurchsatz; »top«, »htop«, »uptime« oder »sar« helfen bei der Überwachung der CPU; »ps«, »top« oder »sar« bei der Bestimmung des Speicherverbrauchs.

Aus den bei Normallast vorgefundenen Werten lassen sich Volllastsituation extrapolieren. Eine Überwachung über SNMP (zum Beispiel mittels Nagios) warnt außerdem vor drohenden Katastrophen. Sind die Schwachstellen ermittelt, sollte überflüssiges Logging abgeschaltet werden.

3. Swappen ist eine Sünde und ein Gräuel vor dem Systemadministrator! Viele Serverdienste erlauben es, die Obergrenze für die Anzahl der maximal laufenden Instanzen festzulegen. Da das Ein- und Auslagern des Speichers andere Plattenzugriffe extrem verlangsamt, warten bei zu hoch angesetzter Obergrenze immer mehr Prozesse auf die Erfüllung ihrer I/O-Aufträge, was zu allem Überfluss zu weiterem Swappen führt.

Alle Dienste dürfen zusammen also nur so viele Instanzen erzeugen, wie im physikalischen Speicher der Servermaschine Platz finden.

RAM oder Platte?

4. Du sollst den Speicher deines Servers nicht unnütz vergeuden! Bei vielen Serverdiensten geht es auch kleiner: Es lohnt sich, nur benötigte Module zu laden oder Pakete entsprechend neu zu kompilieren. So passen mehr Instanzen in den RAM. Apache lädt in der Standardkonfiguration oft unnötig viele Module, bei Postfix ist es unter Umständen sinnvoll, Binaries ohne MySQL, TLS oder LDAP-Support zu bauen. Der Memory-Footprint von CDB ist viel kleiner als jener der Berkeley-DB. Bei Maps mit reinem Lesezugriff spart ein Wechsel des Maptype oft viel Speicher.

5. Du sollst die Partitionen für Daten, System und Log säuberlich trennen! Getrennte Partitionen erlauben es, das für die jeweilige Aufgabe beste Dateisystem zu wählen (zum Beispiel Ext 3 für die System- und XFS für die Datenpartition). Eigene Platten oder Raid-Systeme verhindern, dass der Plattenkopf bei vielen konkurrierenden Zugriffen sinnlos hin und her fliegt.

6. Du sollst die Aktionen deiner Dienste in ein Log schreiben! Ohne Logs stehen keine Daten für die Analyse oder Fehlersuche zur Verfügung. Ein »-« vor dem Namen der Logdatei in »/etc/syslog.conf« aktiviert das asynchrone Schreiben der Logfiles und mindert die Last auf das Dateisystem.