© photocase.com

Ist der Mailserver zu langsam, meutern die User. Wer den Server sinnvoll optimieren will, braucht verlässliche Messwerte über die Geschwindigkeit des MTA. Beim Erzeugen der nötigen Last und beim Sammeln der Resultate hilft ihm das Benchmark-Programm Postal.

Mailserver jonglieren mit Zigtausenden von Nachrichten und kommunizieren viel mit fremden Servern. Dabei sind sowohl SMTP (Simple Mail Transfer Protocol) als auch das Message-Format reichlich vielseitig. Sich in diesem Zusammenspiel als Admin überhaupt zurechtzufinden ist schon schwer genug. Noch komplizierter wird es, wenn die Aufgabe Optimierung lautet – ohne systematisches Vorgehen und Tools wie den hier vorgestellten Postal-Benchmark ein aussichtsloses Vorhaben.

Mailserver-Benchmarks helfen eine Basislinie zu ermitteln, die als Ausgangs- oder Bezugspunkt für künftige Verbesserungen dient. So lässt sich kontrollieren, wie eine Änderung an einem Parameter die Performance beeinflusst. Der Begriff Benchmark übersetzt sich passenderweise mit Bezugswert, Tauglichkeitstest oder Vergleichstest.

Die Anforderungen an Mailserver und damit an die Messtechnik unterscheiden sich je nach Einsatzgebiet. Der Server kann zum Beispiel als Mailrelay dienen, als Kommunikations- und Groupware-Server mit lokalen Mailboxen arbeiten oder als Virenscanner und Spamfilter zwischengeschaltet sein. Je nach Szenario wechselt auch die Position im Netzwerk, mal steht der Server als Mail-Gateway am Internetzugang (Abbildung 1), mal im internen Firmennetzwerk/LAN oder hinter einem Loadbalancer. All das muss ein Benchmark berücksichtigen.

Abbildung 1: Ein Relay-Mailserver in der DMZ muss viele von außen unabhängig voneinander eintreffende Verbindungen verarbeiten, die sich zeitlich überlappen. Er reicht die Mails dann zum internen Server durch.

Laboraufbau

Es ist relativ einfach, per Mailserver-Reporting-Funktion eine Basislinie im Produktivbetrieb zu ermitteln. Ungleich schwieriger zu entwerfen sind sinnvolle generische Testumgebungen für das Benchmarking verschiedener Mailserver unter Laborbedingungen. Abbildung 2 zeigt die typische Topologie für Labormessungen. Ein leistungsfähiger GBit-Backbone verbindet Server und Clients: den Mailserver, einen Client mit der Benchmark-Applikation Postal und eine E-Mail-Senke (Empfänger). In der Realität haben die Antwortzeiten von Directory Services großen Einfluss auf die Performance (LDAP, DNS oder Active Directory, siehe Artikel in diesem Schwerpunkt). Unter Laborbedingungen schließt die Konfiguration des Mailservers solche Störeinflüsse aus.

Abbildung 2: Im Labortest sind ein Postal-Client (er simuliert die E-Mail-Absender), der Mailserver und eine Mail-Senke (das Ziel der weitergereichten Nachrichten) per Switch verbunden.

Lastgenerator

Geeignet parametrisiert bildet Postal jede Last nach, die der Server zu bewältigen hat. Deren Menge und Charakteristik hängen von der Position und den Aufgaben im Netz ab (Abbildung 1). Bei der Simulation eines Mailrelay ist zudem ein zweiter Mailserver nötig, der wahllos ankommende E-Mails annimmt und vernichtet. Sendmail und Postfix lassen sich mit wenig Aufwand als so genannte Mail Sink konfigurieren. Noch leichter klappt es mit dem Perl-Skript von Thomas Aeby [4] aus Listing 1.

01 #!/usr/bin/perl
02 
03 use Net::SMTP::Server;
04 use Net::SMTP::Server::Client;
05 use Getopt::Long;
06 use strict;
07 
08 my $port = 25;                  # Default listen port
09 my $bindaddr = "localhost";     # Bind to localhost only by default
10 GetOptions ("p=i" => $port, "b=s" => $bindaddr)
11   || die "Usage: $0 [-p port] [-b bind-address]";
12 
13 print "setting up server listening on port $bindaddr:$portn";
14 my $server = new Net::SMTP::Server($bindaddr, $port)
15   || die "Cannot setup server: $!";
16 
17 while(my $conn = $server->accept()) {
18   # Got one incoming connection.
19   # Fork off a child process handling it
20   next if( fork() > 0 );
21   my $client = new Net::SMTP::Server::Client($conn)
22     || die "Unable to handle client connection: $!";
23   # Talk to the client
24   $client->process
25     || die "Client didn't send us mail";
26   # log info and terminate
27   system("logger", "-s", "-p", "local1.notice", "-t", "mailsink",
28     "got mail from ".($client->{"FROM"}).
29     " for ".join(",",@{$client->{"TO"}}).
30     ", message size: ".length($client->{"MSG"})." bytes" );
31   exit(0);
32 }

Ohne E-Mail-Senke bliebe immerhin ein vereinfachter Test, bei dem der Client nur Mailheader sendet und die Verbindung schließt, bevor der Body kommt. Die meisten Mailserver werten die Message Header sofort aus, daher fließt dieser Schritt noch in die Messung ein. Diese Technik eignet sich auch, um einen Loadbalancer zu testen, weil sich schnell herausstellt, nach welchem Algorithmus er die Last auf die Server verteilt.

Es mag überraschen, dass ein einfacher Client-PC genügt, um die Leistungsgrenzen eines gut ausgestatteten Mailservers auszuloten. Doch eine Mail erzeugen, mit Buchstabensalat füllen und absenden kostet kaum Rechenzeit und braucht auch keine Festplattenzugriffe. Nur die Netzwerkkarte muss ausreichend dimensioniert sein. Ganz anders beim Parsen der eingehenden Nachrichten auf dem Server – der muss sich mit allen erdenklichen Formaten und Kodierungen auseinander setzen.

Auch der Einfluss der Mail-Senke ist gering, sie muss nur für alle zu vergleichenden Mailrelays identisch bleiben. Ein gutes Relay arbeitet auch dann flott, wenn die Zielserver lahmen und das Relay die Mails in Warteschlangen (Queues) zwischenpuffert. Ein Vergleich bei gleich bleibendem Mailserver und einmal schnellen und einmal langsamen Mail-Senken erlaubt Rückschlüsse auf die Queue-Geschwindigkeit. Sie hängt zum Beispiel vom Filesystem oder den verwendeten NFS-Mounts ab.

Die Schreibvorgänge bei Mailrelays richten sich nach der Verfügbarkeit und Geschwindigkeit der Zielserver. Ihr Schreibverhalten unterscheidet sich aber deutlich von Mailservern mit lokalen Mailboxen: Während ein Relay viele Schreib- und Löschzugriffe hat, häufen sich bei Servern mit lokalen Mailboxen die Schreiboperationen, um ankommende E-Mails an eine (eventuell schon recht große) Mbox-Datei anzufügen.

Postal-Suite

Die Benchmark-Suite Postal besteht aus den drei Kommandozeilen-Programmen »postal«, »postal-list« und »rabid«. Für das SMTP-Benchmarking ist »postal« zuständig, das Zusatz-Utility »postal-list« prüft, wie Postal zur Laufzeit seine Seed-Datei expandiert. Rabid schließlich eignet sich zum Vermessen von POP3- und IMAP-Servern oder es überprüft die auf Platte geschriebenen E-Mails (siehe Kasten “Rabid”).

Um eine realistische Mail-Last zu erzeugen, braucht Postal tausende Mailadressen. Den Anfang macht eine Seed-Datei, die mit E-Mail-Adressen gefüllt ist. Die Manpage bezeichnet diese Datei als User-List. Falls ihre Größe nicht reicht, sorgt ein Zufallsgenerator für den Rest. Die Adressen dürfen aber nicht ganz zufällig sein, sondern müssen bestimmten Regeln folgen. Die definiert der Tester per Regular Expression in der Conversion-Datei, Postal expandiert sie dann in passende Empfängeradressen.

Gut gefüttert

Die Seed-Datei kann einfache Usernamen oder komplette E-Mail-Adressen (mit Domänenname) enthalten. Postal setzt entweder direkt den Inhalt einer vorhandenen Seed-Datei bei den Empfängeradressen ein oder wendet die in der Conversion-Datei beschriebenen Regeln zur Expansion an:

^f .[0-9abc][xyz][ghjjhjlk089765]

Diese Zeile besteht aus einer Regular Expression (hier »^f«) und einer Konversionsvorschrift. Postal sucht zufällig eine E-Mail-Adresse in der Seed-Datei, die auf den regulären Ausdruck passt – hier also mit dem Buchstaben »f« beginnt. Weil die Vorschrift mit einem Punkt beginnt, bleibt das erste Zeichen unverändert. Danach folgen drei Vorschriften in eckigen Klammern, die den zweiten, dritten und vierten Buchstaben der Adresse durch einen aus der Liste ersetzen. E

Mit der vorliegenden Regel gibt es 13 * 3 * 14 = 546 mögliche Expansionen für jede E-Mail-Adresse aus der Seed-Datei, die mit dem Buchstaben »f« beginnt. Alle anderen Adressen ignoriert diese Konversionsvorschrift. Das Kommando »postal-list Seed-Datei Conversion-Datei« zeigt alle Expansionen an. Ein simples »| wc -l« angehängt, zählt die insgesamt möglichen Adressen.

Passendes Muster

Muster und Seed müssen zur Größe des Unternehmens passen. Wer einen Mailserver testen will, der als Relay oder Groupware-Server 35 000 Mitarbeiter versorgt, wäre mit einem Pattern, das nur zu 500 E-Mail-Adressen expandiert, schlecht beraten. Umgekehrt braucht eine kleine Druckerei mit 80 Mitarbeitern keine Seed-Datei, die 20 000 Adressen ergibt.

Bei der Betreffzeile und dem Nachrichteninhalt gibt sich Postal viel weniger Mühe und füllt sie mit zufälligem Buchstabensalat. Wer in einem Test echte Empfänger-Mailboxen verwendet, erkennt darin die Postal-Nachrichten am zusätzlichen Headerfeld »X-Postal« und kann sie automatisch aussortieren.

Ab die Post

Vor dem Start von Postal ist zu klären, was man simulieren und testen will: ein Mailrelay, einen Groupware-Server oder ein anderes Szenario. Davon hängt ab, wie die wichtigsten Postal-Parameter lauten (Tabelle 1). Das Parameter-Set bestimmt zum Beispiel die Anzahl an simulierten Clientcomputern, die sich zum Mailserver verbinden. Bei Groupware-Servern, Virenscannern oder Spam-Filtern im LAN sind das meist nur ein bis zwei Clients. Der Parameter »-p« (parallele Postal-Prozesse) erhält dazu einen kleinen Wert und »-c« ist groß (Mails pro Connection). Bei Mailrelays und ISP-Servern hängt der genaue Wert von der Größe des Providers ab. Jedenfalls wird »-p« groß sein und dafür »-c« klein.

Zusammen mit den »-c«- und »-p«-Werten erfährt Postal beim Start, welche Seed- und Conversion-Dateien der Aufrufer wünscht:

postal -c Nachrichten -p Prozesse Seed-Datei Conversion-Datei > Ausgabedatei

Wer keine Conversion-Datei verwenden will und sich mit der fertigen Seed-Liste begnügt, setzt ein einfaches Minuszeichen »-« in die Parameterliste. Nützlich ist oft auch der Parameter »-m«. Er bestimmt die maximale Größe der gesendeten E-Mails. Per Default liegt dieser Wert bei sinnvollen 10 KByte. Postal sendet Mails zufälliger Größe zwischen 0 KByte und der in »-m« angegebenen Größe. Wer erwartet, dass im produktiven Betrieb viele Mails mit großen Attachments eingehen, setzt »-m« entsprechend höher. Viele Mailserver-Reporting-Programme zeigen die durchschnittliche Größe eingehender E-Mails via GUI.

Dauertest

Eine interessante Option für Langzeittests und zur Qualitätssicherung ist »-r«. Sie legt fest, wie viele Mails pro Minute Postal maximal sendet. Im Produktivbetrieb kann Postal bei kleinem »-r« den Betrieb ohne zusätzliche Störung beobachten. Der Client darf guten Gewissens ein paar Wochen laufen. Im Ergebnis zeigt sich vielleicht, dass jeden Tag zur gleichen Zeit die Performance einbricht. Wenn just zu diesem Zeitpunkt das Backup der User-Mailboxen läuft, ist die Ursache auch schon gefunden.

In die Ausgabedatei schreibt Postal die ermittelten Messwerte als CSV-Liste (Comma Seperated Values) zusammen mit allen aufgetretenen Fehlermeldungen. Relativ häufig sind zum Beispiel Lesefehler. Listing 2 zeigt einen kurzen Ausschnitt aus einem Testlauf, aus dem die Fehlermeldungen bereits entfernt sind. Die erste Spalte nennt den Zeitpunkt (Stunde:Minute), dahinter folgen die Zahl der erfolgreich gesendeten Nachrichten, die Gesamtgröße aller Mails in dieser Minute in KByte, die Anzahl aufgetretener Fehler, die Anzahl an Verbindungen und abschließend die Menge der SSL-Verbindungen.

01 $ postal -p200 -c 4 10.0.0.110 ./postal-user -
02 time,messages,data(K),errors,connections,SSL connections
03 21:31,6869,37177,0,2929,0
04 21:32,7241,38282,1,2913,0
05 21:33,7095,37838,0,2836,0
06 21:34,6390,34206,10,2559,0
07 21:35,7458,39774,0,2974,0
08 21:36,7353,39646,0,2911,0
09 21:37,7433,39269,0,2976,0

Die erwähnten Fehlermeldungstexte sind zwar sehr interessant, um den Ursachen auf die Spur zu kommen, beim Import in eine Tabellenkalkulation stören sie aber. Dieser Import ist recht praktisch, um beispielsweise den zeitlichen Verlauf der Messung grafisch nachzuvollziehen oder einen Durchschnittswert zu berechnen (Abbildung 3).

Abbildung 3: Die Postal-Ergebnisse lassen sich in einer Tabellenkalkulation öffnen (hier Open Office Calc), um den zeitlichen Verlauf als Kurve darzustellen (rechts) oder Durchschnittswerte zu berechnen (links unten).

Meist zeigt sich, dass die Durchsätze zu Messbeginn sehr hoch sind, dann abfallen, um sich später um einen konstanten Wert einzupendeln. Das kann zum einen daran liegen, dass der Mailserver seine Queues so weit wie möglich im RAM hält. Zum anderen kann es auch am Schreibcache der Plattensysteme liegen. Um einen aussagekräftigen Wert zu liefern, muss der Benchmarktest mehrere Stunden laufen.

Fehler vermeiden

Interessant bei der Auswertung ist auch, dass Postal die Fehler nicht nur als Meldung ausgibt, sondern in der Ergebnisdatei auch als Error-Rate (Fehler pro Minute) verewigt, ein gelegentlicher Lesefehler ist bei Mailservern üblich. Meist ist es sinnvoller, einen stabilen Betrieb mit wenigen Fehlern anzustreben und dafür mit etwas geringerem Durchsatz zu leben, als um jeden Preis das System zu beschleunigen.

Jede Auswertung sollte übrigens damit beginnen, pro Server nachzuprüfen, ob er wirklich mit vergleichbaren Mails zu kämpfen hatte. Dazu genügt es, die Menge der Daten in KByte durch die Anzahl der E-Mails zu teilen. Wenn bei einem Server 5,3 KByte herauskommt und bei einem anderem 8,8 KByte, dann sind die Ergebnisse nicht vergleichbar.

Spuren lesen

Während des Laufs legt Postal im aktuellen Verzeichnis eine Logdatei namens »postal.log« mit den MD5-Prüfsummen aller gesendeten Mails an. Der Sinn dieser Datei erschließt sich nicht ganz: Die Prüfsummen stehen auch direkt in den versendeten Mails. Rabid überprüft, ob alle Mails unbeschadet angekommen sind: Es holt sie per POP3 vom Server ab und vergleicht die eingebetteten MD5-Summen (siehe Kasten “Rabid”).

Weil E-Mails über das Netzwerk ankommen, lautet eine verbreitete Annahme, dass die wichtigste Optimierung für einen Mailserver den TCP-Protokollstack betrifft (siehe Kasten “TCP beschleunigen”). Die Praxis zeigt aber, dass Verzögerungen im Netzwerk gegenüber Verzögerungen durch Festplatte und Filesystem meist vernachlässigbar sind. Eine einzelne SCSI-Disk kann gegenwärtig etwa 200 MBit/s schreiben, eine gut optimierte GBit-Netzwerkkarte liest ein Vielfaches davon vom Netzwerk.

net.core.wmem_max = 16777216
net.core.rmem_max = 16777216

net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

net.ipv4.tcp_no_metrics_save = 1

Ein Mailserver funktioniert folglich besser mit vielen kleinen, aber schnellen SCSI-Disks im Raid-Verbund, als mit wenigen großen Disks. Letzteres ist heute aber häufiger anzutreffen. Bei den in den vergangenen zwölf Monaten im Linux-Magazin ermittelten Benchmarks war zu beobachten, dass viele kommerzielle Mailserver folgerichtig versuchen, alle Queue-E-Mails im RAM zwischenzuspeichern und die Festplatte erst dann benutzen, wenn der Hauptspeicher nicht mehr ausreicht.

Selber messen

Wer jenseits pauschaler Optimierungstipps wissen will, was sein eigener Mailserver zu leisten vermag, ist mit Postal gut beraten. Das Programm generiert zuverlässig eine Last, an der Messungen verlässlich und vergleichbar werden. Gut informiert kann der Admin dann auch die richtigen Kompromisse beim Optimieren eingehen. (fjl)