Die Firmen-Homepage ist seit 11.20 Uhr auf Slashdot verlinkt, das neue Massenmailing soll raus und die Datenbank muss Umfragedaten in Rekordzeit ausspucken: Dieser Artikel erklärt, mit welchen Techniken der Server die Belastung übersteht.

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.

Sicher aufbewahren

7. Du sollt die aktuelle Konfiguration vor jeder Änderung sichern! Kleine Änderungen verschlechtern leicht unerwartet die Performanz des Servers. Bis der Grund gefunden ist, vergeht wertvolle Zeit. Ein Systemadministrator sollte daher für Konfigurationsdateien eine Versionskontrolle benutzen oder bei Änderungen zumindest ein Backup anlegen. So kann er schnell reagieren, wenn sich die Kunden über einen plötzlichen Geschwindigkeitseinbruch beschweren.

8. Du sollst alle unveränderlichen Dinge in deinem Cache bewahren! Caches helfen in vielen Situationen: Reverse Proxies (zum Beispiel Squid) vor Datenbank-basierten CMS-Systemen reduzieren die Last auf die Datenbank. Caching-DNS-Server (zum Beispiel Dns-Cache, Bind) ersparen bei Log-Analysatoren und Mailservern unnötige DNS-Anfragen. Der eingebaute Cache im Virenscanner Amavisd New verhindert die wiederholte Analyse des gleichen Inhalts.

Türsteher gefragt

9. Du sollst ungebetene Gäste so früh wie möglich abweisen! Wer gar nicht erst an den Server herankommt, kann auch keine Last erzeugen. Eine Firewall, eine Zugriffskontrolle sowie »smtpd_*_checks«-Checks in Postfix verweisen ungebetene Gäste in die Schranken, bevor sie unnötige Systemlast verursachen. Der Anvil-Server in Postfix [1] limitiert außerdem die Zahl der Mails, die der Server pro Zeiteinheit annimmt, auf jene Anzahl, die er ohne für die Performanz schädliches Queueing bearbeiten kann. Cband [2] sorgt für eine vergleichbare Limitierung der Bandbreite beim Apache Webserver.

10. Du sollst leise anklopfen! Portknocking ist ein Ressourcen-schonender Weg, die Firewall komplett dicht zu halten und vertrauenswürdigen Benutzern dennoch ein Login zu ermöglichen [3]. Auch One-Time-Passwörter oder das Verbiegen von Diensten wie SSH auf unbekannte Ports tun der Sicherheit gut und verhindern zudem, dass ungebetene Besucher die CPU beschäftigen.

Webserver

Ist die Adresse einer Webseite an einer viel besuchten Stelle veröffentlicht worden, lässt ein sprunghaftes Anwachsen der Seitenbesuche meist nicht mehr lange auf sich warten. Charly Kühnast, für die Firewalls und die DMZ zuständiger Systemadministrator in einem niederrheinischen Rechenzentrum, rät für diesen Fall:

1. Du sollst das richtige Multiprocessing-Modul wählen! Das MPM »prefork« spaltet eine Reihe identischer Apache-Prozesse ab und eignet sich am besten für Maschinen mit bis zu zwei Prozessoren. Je mehr CPUs ein Webserver hat, umso eher ist das »worker«-MPM, das mit mehreren Threads per Prozess arbeitet, die bessere Alternative.

2. Du sollst den Cache gebührlich nutzen! Apache bietet mit »mod_disk_cache« und »mod_mem_cache« zwei Mechanismen, häufig abgerufenen Content zu cachen. Wer viel RAM hat (was ohnehin durch nichts zu ersetzen ist), liegt mit »mod_mem_cache« [4] richtig.

Ballast über Bord

3. Du sollst Ballast abwerfen! Der Htaccess-Mechanismus ist unbestreitbar nützlich, aber auch ein Performance-Killer. Weg damit also, wenn er nicht gebraucht wird: »AllowOverride None« erspart das zeitaufwändige Parsen von ».htaccess«.

4. Du sollst noch mehr Ballast abwerfen! Aus dem Weg schaffen sollte der Sysadmin auch Symlinks (»Options -FollowSymLinks«) und alle nicht benötigten Module. Die optimale Lösung ist, Apache mit allem, was man benötigt, statisch zu kompilieren und überhaupt keine Module zur Laufzeit nachzuladen.

5. Entsage den Lookups! Hostname-Lookups sind Bremsen, selbst bei schnellen Nameservern. »HostnameLookups off« beseitigt diesen Hemmschuh. Wer die Information dringend benötigt, kann die Lookups später beim Auswerten der Logs von einem Tool wie Webalizer erledigen lassen.

6. Du sollst deine Clients ehren und möglichst nicht warten lassen. Die »MaxClients«-Direktive ist zentral für die Performance. Ist sie zu niedrig angesetzt, werden nicht alle Clients zeitnah bedient, ist sie zu hoch, dümpeln die Clients in der TCP-Warteschlange. Der richtige Wert lässt sich nur durch Lasttests herausfinden.

7. Lass ab von unnötigen Logfiles! Logging kostet Zeit. Jedes Logfile, das niemand mehr braucht, ist bereits zu viel. Wird auf externe Platten geloggt, sollte es sich dabei um ein sehr schnell angebundenes SAN handeln, NFS ist in aller Regel eine Bremse.

8. Du sollst Sendfile nutzen! Sendfile ist ein Systemcall, der das Ausliefern von Files auf Netzwerk-Sockets an den Kernel delegiert. Das spart Speicher (Verzicht auf Read-Buffer) und ist außerdem schneller. Apache nutzt Sendfile nach Aktivierung von »EnableSendfile«.

9. Du sollst MMAP ehren und achten! MMAP-Unterstützung über das Module »mod_mmap_static« erlaubt es Apache, ein File wie einen durchgängigen Speicherbereich anzusprechen, was der Performance gut tut.

10. Du sollst nicht begehren deines Servers Monitoring! Die Apache-Selbstüberwachung (Stichwort: »SetHandler server-status…«) ist nützlich für Tests und Debugging. Nach Abschluss der Tests gehört sie ausgeschaltet.

Mailserver

Wenn der Mailserver unter der Last zusammenzubrechen droht, sind klare Prioritäten zu setzen: Zunächst ist wichtig, dass das System stabil bleibt und trotz der hohen Last effektiv arbeitet. Erst dann sollte die Verarbeitungsgeschwindigkeit im Zentrum des Interesses stehen. Peer Heinlein, LPI-Trainer und Buchautor bei Open Source Press, gibt Tipps für die Praxis.

1. Du sollst die Instanzenzahl beschränken! Der Defaultwert in der »master.cf«-Datei von Postfix legt die Anzahl der maximalen Instanzen auf 100 fest. Je nach Version und einkompilierten Fähigkeiten kostet eine Instanz etwa 3 MByte RAM, sodass bei einem Server mit wenig Speicher eine Out-of-Memory-Condition und damit ein Systemabsturz droht. Auch Spam- und Virenkiller ziehen erhöhten Speicherbedarf nach sich, wenn mehrere Instanzen parallel laufen.

Gerät der Server durch Swappen ins Stocken, ist es sinnvoll, die Instanzenzahl deutlich zu reduzieren. Viele parallele Instanzen auf einem überlasteten System behindern sich gegenseitig und führen zu einer starken Verschlechterung des Datendurchsatzes (Abbildung 2).

Abbildung 2: Klassisches Absturzszenario: Steigt die Prozesszahl unter Last so stark, dass die Maschine zu swappen beginnt, wächst allein wegen des sinkenden Durchsatzes die Last noch weiter. Das Ende vom Lied ist im schlimmsten Fall ein Out of Memory.

2. Du sollst dem Spamfilter mit einer RAM-Disk auf die Sprünge helfen! Ein Spam- und Virenfilter wie Amavisd New oder Spamassassin bildet auf Mailservern oft einen Engpass: Er sorgt für große CPU- und I/O-Last und bestimmt so den Gesamtdurchsatz des Systems. Abhilfe schafft hier, »/var/spool/amavis/tmp« in eine RAM-Disk auszulagern (Abbildung 3). Aufgrund der höheren Performanz verträgt der Server nun etwa 14 statt der sonst als Maximum empfohlenen sieben Instanzen des Spamfilters. [5] untermauert das mit Messergebnissen und Auswertungen.

Abbildung 3: Gewinnbringend angelegt: Da Applikationen wie Spam- oder Virenfilter auf Mailservern viele Dateizugriffe brauchen, lohnt es sich in vielen Fällen, in eine RAM-Disk für das Arbeitsverzeichnis der auf dem Server laufenden Filtersoftware zu investieren.

Um- und Irrwege vermeiden

3. Du sollst DNS-Anfragen cachen! Alle Mailserver leben vom DNS und müssen unzählige Abfragen bewältigen: Wer sind die MX-Server einer Domain? Gibt es eine Absenderdomain überhaupt? Steht ein Client auf einer RBL-Liste? Ein in »/etc/resolv.conf« eingetragener DNS-Server im eigenen Netz, der Anfragen zwischenspeichert, spart bei großen Mengen wertvolle Millisekunden.

4. Du sollst dich nicht auf Um- und Abwege begeben! Das übliche Verfahren leitet Mails von Postfix an den Spam- und Virenfilter weiter. Diese geben die Mails dann wieder an Postfix zurück. Kommen sogar weitere Appliances zum Einsatz, folgen weitere Runden.

Besser ist es, die Mails vom Viren- oder Spamfilter nicht wieder an Postfix zurückzuleiten, sondern gleich an die nächste Appliance weiterzugeben. Wenn es sich klar definiert nur um eingehenden Mailverkehr handelt, kann die letzte Appliance in der Kette die E-Mails direkt an einen internen Mailserver weitergeben, statt sie an Postfix zurückzuleiten.

Zuständigkeit prüfen

5. Du sollst nur reagieren, wenn du zuständig bist! Wer Mails annimmt, obwohl er sie gar nicht zustellen kann und noch dazu ein Bounce erzeugen und ausliefern muss, wirft seine Ressourcen mit beiden Händen zum Fenster hinaus. Der Einsatz von »local_recipient_maps« und »relay_recipient_maps« bewirkt, dass Postfix nur Mails für Accounts annimmt, die es tatsächlich gibt. Das vermeidet unnötige Last, wenn Spammer einfach Adressen ausprobieren.

Ähnliches gilt für Absenderadressen: Existiert die enthaltene Domain nicht, handelt es sich kaum um erwünschte Mail. Eine Antwort ist auf jeden Fall unmöglich. »reject_unknown_sender_domain« investiert für die Gesamtperformanz gewinnbringend in eine DNS-Abfrage, um dies zu klären, bevor der Server die Mail annimmt.

6. Du sollst nur lokale Dateien als Posfix-Lookup-Tables einsetzen! So komfortabel eine User- oder Domainverwaltung in MySQL oder LDAP sein mag, so negativ wirken sich die Abfragen auf die Postfix-Performance aus. Eine Lookup-Table im Format »hash« oder noch besser »btree« ist wesentlich schneller. Es lohnt sich, ein Skript zu schreiben, das halbstündlich die aktualisierten Nutzdaten aus der MySQL- oder LDAP-Tabelle in eine lokale Datei auf dem Server schreibt.

7. Du sollst dir lästige Clients mit Rate-Limiting von Halse halten! Belästigt ein einzelner Client den Mailserver oder findet gar ein Angriff statt, verhindert Rate-Limiting über den Parameter »smtpd_client_connection_rate_limit«, dass dies den restliche Mailverkehr beeinträchtigt. Auch eine Firewall kann die maximale Anzahl der Connects begrenzen und damit verhindern, dass Rückläufe aus gehackten Clients Hunderte von Verbindungen öffnen.

8. Du sollst dich nicht mit Problemmails aufhalten! Staut sich der ausgehende Mailverkehr, kann das auch daran liegen, dass Postfix Ressourcen für viele unzustellbare Nachrichten verpulvert. »maximum_backoff_time« legt die Zeit fest, nach der Postfix spätestens einen erneuten Zustellversuch unternimmt. Ein Erhöhen dieses Werts gibt mehr Rechenzeit für wahrscheinlich erfolgreiche Erstversuche frei, statt sie für wahrscheinlich weiterhin nicht ziehlführende Wiederholungsversuche zu vergeuden. Alternativ bietet der Parameter »fallback_relay« die Möglichkeit, solche Problemmails auf eine andere Maschine zu verschieben, die dann die Schmutzarbeit für den eigentlichen Server erledigt.

Datenbankserver

Was ist die Ursache, wenn die Datenbank Datensätze nur zögerlich liefert, die CPU aber praktisch unbeschäftigt ist? Neben der Qualität der einzelnen SQL-Abfragen tragen auch Datenbankdesign und Serverkonfiguration wesentlich zur Performance einer Datenbank bei. Badran Farwati, seit sieben Jahren Datenbank-Administrator und Programmierer und zurzeit Oracle-Senior in der Österreichischen Nationalbibliothek, erklärt, wie sich die Performanz eines Datenbankservers steigern lässt.

1. Du sollst die richtigen Indizes wählen! Eines der wichtigsten Elemente einer Datenbank sind die Indizes: Antwortzeiten des Servers hängen entscheidend von ihrer Qualität ab. Ein B*TREE-Index (der Default-Index-Typ in vielen Datenbanken) sollte zum Einsatz kommen, wenn die indizierte Spalte viele verschiedene Werte annehmen kann. Der Suchbaum dieses Indextyps wächst am langsamsten. Für Spalten, die nur wenige verschiedene Werte (etwa Produktgruppen) aufnehmen kann, empfiehlt sich stattdessen ein Index vom Typ Bitmap bei Oracle oder ein entsprechender Typ bei anderen Datenbanken.

Bei Tabellen aus wenigen Zeilen ist ein »TABLE ACCESS (FULL)« (in MySQL ein »FULL TABLE SCAN«) schneller als ein Zugriff über den Index. Nutzen viele Abfragen eine Funktion wie »UPPER(Spalte xyz)«, sorgt ein Index über das Ergebnis dieser Funktion für eine bessere Performanz. Vorausgesetzt die eingesetzte Datenbankengine unterstützt funktionsbasierte Indizes [6].

2. Du sollst unnötige Indizes löschen! Der Oracle Optimizer benutzt keine Indizes, die in einem Statement nicht gebraucht werden. Unabhängig davon, ob ein SQL-Statement sie verwendet oder nicht, lädt die SQL-Engine dennoch alle für eine Tabelle definierten Indizes. Das kostet I/O-Ressourcen und belastet außerdem die CPU.

3. Du sollte fragmentierte Indizes vermeiden! B*TREE-Indizes fragmentieren mit der Zeit durch Updates oder Inserts in einer Tabelle, was Abfragen erheblich verlangsamt. Der Fragmentierungsgrad lässt sich in Oracle mit der Anweisung »ANALYZE INDEX Index-Name VALIDATE STRUCTURE« ermitteln. Mit »ALTER INDEX Index-Name REBUILD ONLINE« kann der Index neu aufgebaut werden. Unter MySQL bauen »ANALYZE TABLE« und »OPTIMIZE TABLE« einen fragmentierten Index neu auf.

Der richtige Ausdruck

4. Du sollst deine SQL-Statements optimieren! SQL ist eine flexible Sprache. Meist führen viele Wege zum gleichen Ziel. Oft unterscheiden sich die Ansätze jedoch in ihrem I/O-Ressourcenverbrauch. »EXPLAIN PLAN« unter Oracle oder »EXPLAIN« in MySQL helfen bei der Optimierung: Diese Befehle erklären, wie die SQL-Engines die Abfragen aufbauen, ob und welche Indizes sie verwenden und wie viele Zwischenergebnisse die Datenbank erzeugt. Ab MySQL 5.1 steht »EXPLAIN PARTITIONS« für die Analyse des Laufzeitverhaltens partitionierter Tabellen zur Verfügung [7].

5. Du sollt das Soft Parsing, das dir deine Datenbank zur Verfügung stellt, gebührlich nutzen! Die Datenbankengine parst SQL-Abfragen als Literal, also wörtlich. Selbst zwischen identen Abfragen, die sich nur in einem einzigen Literal unterscheiden (zum Beispiel »SELECT…WHERE x=100…« und »SELECT…WHERE x=200…«) stellt die Engine daher keinen Zusammenhang her. Sie legt eine Kopie von jeder Abfrage im Shared Pool des Speichers ab.

Wiederholen sich Abfragen, die sich nur in einem Literal unterscheiden, hundertmal, legt die Datenbank sie hundertmal im Speicher ab (Hard Parse). Das führt zu einer Speicherfragmentierung. Eine Vergrößerung des RAM hilft nur bedingt weiter. Verwendet die Abfrage jedoch in der »WHERE«-Klausel statt eines Literals einen Platzhalter (Befehl »BIND SQL«), legt die Engine die SQL-Abfrage mit diesem Platzhalter im RAM ab und verändert sie bei einem erneuten Aufruf nicht mehr (Soft Parse).

Teile und herrsche

6. Du sollt die Größe deiner Tabellen begrenzen! Tabellen mit Millionen von Datensätzen führen zu hohem Verbrauch von I/O-Ressourcen. Eine Möglichkeit, diesen Bedarf zu reduzieren, ist es, große Tabellen in mehrere Blöcke zu zergliedern. Seit Oracle 8 und MySQL 5.1 lassen sich Tabellen partitionieren. Bei SQL-Statements, die nur bestimmte Spalten in der »WHERE«-Klausel referenzieren, muss der Parser nur die relevanten Partitionen durchsuchen (Abbildung 4). Partitionierung hilft besonders bei Batch-Jobs, die Teile einer Tabelle updaten.

Abbildung 4: Ab Version 5.1 auch bei Mysql möglich: Partitionierte Tabellen ersparen es dem Parser, bei Abfragen, die nur eine oder wenige Spalten betreffen, die ganze Tabelle einzulesen. Das schont die Rechnerressourcen.

7. Du sollst OLTP und DSS säuberlich trennen! Verschiedene Arten der Nutzung einer Datenbank führen zu unterschiedlichen Anforderungen an die Rechnerressourcen: Decision Support Systems (DSS, [8]) wie Recherche- oder Suchsysteme führen in der Regel vor allem Selects und damit verbundene Sortiervorgänge, aber fast keine Insert-, Update- oder Delete-Aktionen aus.

Ein Online Transaction Processing System (OLTP, [9]) hingegen, zum Beispiel ein Online-Bestellsystem oder ein Content-Managementsystem, bedient in der Regel gleichzeitig hunderte User, die auch die Daten verändern. Damit ändern sich auch die Indextabellen rasch.

Die richtige Wahl des Index ist also für die Performanz entscheidend. Bedient ein Datenbankserver beide Nutzungsszenarien, sollte man je nach Schwerpunkt eine CPU-Priorität für die unterschiedlichen Nutzungstypen festlegen. Unter Oracle geht dies am einfachsten mit dem Resource Manager [10].

8. Du sollst persistente Verbindungen und den Shared Server nutzen! Der wiederholte Aufbau bei nicht persistenten Verbindungen kostet Ressourcen. Andererseits startet Oracle auf einem Dedicated Server einen Prozess für jede Verbindung und hält diesen auch im Speicher, wenn der Anwender nicht auf die Datenbank zugreift. Deshalb bietet Oracle eine Shared-Server-Lösung, die Prozesszahlen niedrig hält, indem sie Connections und Abfragen in einem großen Pool verwaltet. Das schont die Ressourcen besonders bei OLTP-Systemen.

9. Du sollst auf das Timing der Batch-Jobs achten! Batch-Jobs sollten ausschließlich während zugriffsarmer Zeiten in der Nacht laufen.

10. Du sollst die Anzahl der Verbindungen kontrollieren! Am effektivsten ist es, Applikations- und Webserver vom Datenbankserver zu trennen. Auf jeden Fall sollte die maximale Zahl der Prozesse auf beiden Seiten gut abgestimmt sein: Ist die maximale Zahl der Prozesse am Webserver höher als in der Datenbank, kann dies zu einer Überflutung mit Verbindungen zur Datenbank führen, die auf die überzähligen Prozesse nicht mehr reagieren kann.

Die Apache-Direktiven »MaxClients«, »KeepAlive«, »MaxSpareServers« sowie »MaxRequestsPerChild« müssen zu den Oracle-Einstellungen passen: Die Parameter »SESSION« und »PROCESS« und die Entscheidung, ober der Shared Server zum Einsatz kommt, haben hier Einfluss auf die Zahl der maximal möglichen Verbindungen. Unter MySQL regeln dies »max_connections« und »max_user_connections«.

Samba

Wenn der Samba-Server die Daten nur zögerlich liefert, wird das Öffnen und Speichern von Dateien zur Geduldsprobe und zieht so die Produktivität der ganzen Firma in Mitleidenschaft. Volker Lendecke, Mitglied im Samba-Team und Mitbegründer der Service Network GmbH erläutert, wie sich dieser Hemmschuh aus dem Weg räumen lässt.

1. Du sollst nicht berühren deine Samba-Konfiguration! Samba hat in der Standardkonfiguration die optimalen Einstellungen, um für Windows-Clients die bestmögliche Leistung zu bringen. Wenn Performance-Probleme auftreten, sollte man zunächst alle Optionen, die nicht unbedingt notwendig sind, aus der Konfigurationsdatei »smb.conf« herausnehmen und erst dann Schritt für Schritt neu einstellen.

2. Du sollst dich beim RAM freigiebig zeigen! 2 bis 3 MBytes echter Hauptspeicher pro angemeldetem Benutzer sind das Minimum für einen performanten Samba-Server. Jedes Byte mehr kann das System für leistungssteigernde Caching-Zwecke verwenden.

3. Du sollst dein Netzwerk prüfen! Wenn der Samba-Dateitransfer langsam ist, empfiehlt sich ein Gegentest mit FTP. Das sehr einfaches Protokoll, das nur reine TCP-Datenströme benutzt, zeigt die über das Netzwerk maximal mögliche Transferrate.

Nützliche Helfer

4. Du sollst die Oplocks aktivieren! Ein Opportunistic Lock oder Oplock dient nicht dazu, bestimmte Dateien für einen Benutzer exklusiv zu reservieren. Es erlaubt vielmehr dem Client, den Inhalt der Datei zu cachen. Der Server sichert dadurch einem Client zu, dass gleichzeitig niemand sonst auf die Datei zugreift. Sobald ein zweiter Benutzer sie öffnet, informiert der Server den Client und dieser gibt das Oplock auf (Abbildung 5). Erst dann sendet der Client die Schreibzugriffe zum Server, was in der Praxis viel Netzwerkbandbreite spart.

Abbildung 5: Operative Locks machen beim Schreibzugriff auf eine Datei die Synchronisation zwischen Clients und Server überflüssig, wenn nur ein Benutzer auf die Datei zugreift. Erst beim Zugriff eines weiteren Benutzers hebt der Server das Lock auf und der Client sendet die veränderte Datei zurück..

5. Du sollst Winbind starten! Ohne Winbind muss der Samba-Daemon für jeden neuen Benutzer eine eigene Verbindung aufbauen, was inklusive Overhead etwa 40 bis 60 IP-Pakete ausmacht. Winbind senkt dies auf drei Pakete, indem es ständig eine Verbindung zum Domain Controller offen hält

6. Du sollst keinen Unterschied machen zwischen Groß- und Kleinschreibung! Da Windows nicht zwischen Groß- und Kleinschreibung bei Dateinamen unterscheidet, Unix aber sehr wohl, muss Samba, wenn Windows eine Datei »test.txt« anlegen will, sicherstellen, dass es »Test.txt« nicht gibt. Bei Verzeichnissen mit über tausend Einträgen verbraucht dieser Scan viele Ressourcen. Wenn möglich, sollten daher mit Samba verwaltete Verzeichnisse nur wenige Dateien enthalten. Geht dies nicht, ist es sinnvoll, den Scan mit »case sensitive = yes«, »preserve case = no« und »default case = lower« abzuschalten. Samba zeigt dann sämtliche Dateinamen in Kleinbuchstaben an.

Ruhiges Gewissen

Abends 18:30 Uhr: Die Responses-Zeiten des Webservers mit der auf Slashdot verlinkten Seite bleiben im Rahmen. Das Massenmailing hat die Empfänger erreicht und die Datenbank die Umfrage zügig ausgewertet. Da die Server nach allen Regeln der Kunst optimiert sind, ist es Zeit für den gestressten Systemadministrator, mit einem ruhigem Gewissen nach Haus zu fahren. (pkr)