[Postfixbuch-users] OT: Dovecot Mailstore extern

Do Sep 30 16:04:10 CEST 2010

Hi,

nur kurz zwei Anmerkungen:
Ganz egal wie schnell Du NFS optimiert bekommst:
  jedes Clusterfilesystem ist schneller -
  natürlich auch etwas komplizierter.

Beim GPFS von IBM hast Du keinen dedizierten Meta-Data-Server,
Volker Lendecke hat mal einen Benchmark irgendwo gezeigt
Performance gegen GPFS Server - mit linearem Anstieg....
Da Win nicht gerade Netzwerk freundlich ist schon beachtenswert.

Auf der anderen Seite sind Mails als einzelne Datei immer etwas
"besonders".

Letztendlich, wenn man etwas funktionierendes hat, dann sollte man dabei
bleiben.

Wenn man Zeit und Geld zum spielen hat, dann kann man auch
2-3 Monate alles systematisch durch messen. Aber dann kannst Du auch 
anfangen Dein Netzwerk-Equi. zu optimieren, das *kann* auch noch mal 
locker 5-25% bringen.

Die große Frage ist, ob die höhere Geschwindigkeit vom Nutzer/Kunden 
überhaupt wahrgenommen wird. Brauchst Du jetzt 8 oder 12ms um die Mail
anzuzeigen ?

Ciao, Peer

Am 29.09.2010 12:16, schrieb Peer Heinlein:
> Am Mittwoch, 29. September 2010, 11:16:31 schrieb Oliver Pürsten:
>
>
>> Keiner sonst irgentwelche Erfahrungen mit Dovecot und den Mails nicht auf
>> der der lokalen Machine?
>
> Ja, hatten wir vor einigen Jahren mal mit 30.000 Accounts, allerdings freue
> ich mich hier auch auf mittlerweile direkte SAN-Anbindung per FC.
>
> Ein anderer Kunde hat 130.000 Accounts im SAN und gibt das per NFS-Kopf an
> die IMAP-Server frei.
>
> Ich hätte mir da eine schönere Lösung gewünscht, aber wegen verschiedener
> Hakeleien sollte das am Ende dann bei NFS bleiben. Im Prinzip läuft dort
> alles prima nachdem wir NFS zwei Runden lang ordentlich gepimpt haben, auch
> wenn raw vielleicht etwas schneller wäre.
>
> In meinen Augen ist NFS zu unrecht als lahm und böse verschriene. NFS
> **KANN** auch sehr schnell und gut sein. Das ist in aller Regel eine Frage
> der NFS-Implementierung (Linux, Sun, NetApp -- da sind schon Unterschiede
> und unterschiedliche Versionen sowieso nochmal) und dann auch eine Frage des
> NFS-Tunings.
>
> Gerade mit den Blockgrößen zum Lesen und Schreiben (rsize&  Co) habe ich da
> beim pimpen gute Erfahrungen gemacht.
>
> Das Problem ist halt: NFS liest die Blöcke einer Datei sequentiell, also
> nacheinander. Und dort entsteht halt Latenz. Die entsteht prinzipiell auch
> bei einer Festplatte (darum gibt es ja auch readahead), nur kommen da eben
> keine Zeiten zusammen. Bei 20-40 ms Paketlaufzeit im Netzwerk aber durchaus.
>
> Wenn ich eine Blockgröße rsize=1024 habe und jede Mail ist 1500 Bytes groß,
> dann sind das zwei nacheinander gelesene Blöcke. Anfordern - Empfangen -
> Bestätigen - Anfordern - Empfangen - Bestätigen.
>
> Wenn man sowas durch rsize=2048 in einen Block packt, sieht sowas sofort
> ganz anders aus.
>
> Die Default-Blockgrößen sind sehr schlecht und widersprüchlich dokumentiert.
> In aller Regel haben moderne Kernel heute sowieso schon 8192 Bytes und damit
> kriegt man dann 95% der Mails in einem Rutsch gelesen/geschrieben, so daß
> Latenz kaum Auswirkungen hat.
>
> Hier darf man halt eine Rückschlüsse von uralt-Systemen auf heute Systeme
> schließen, bzw. von suboptimaler Konfiguration auf optimale.
>
> Wenn ich bei IP eine MTU von 280 Bytes habe, dann kann ich schließlich auch
> beweisen, daß TCP/IP scheiße weil lahm ist. Gar kein Problem, wenn jedes IP-
> Paket erstmal fragmentiert und mit Overhead übertragen werden muß. Und
> genauso sehe ich das auch bei NFS.
>
> Ein anderer Punkt ist die Fragem, wieviele parallele NFS-Requests die kernel
> wohl können, sprich: Was machen sie noch parallel, was dann schon wieder
> sequentiell.
>
> Wenn Dovecot 200 Dateien anfordert und die auch parallel kriegt, dann ist
> die Latenz pro Datei nicht mehr so wirklich wichtig. Wenn er aber nur
> maximal 8 oder 16 parallel kriegt und das ganze also in 25 sequentiellen
> Slots a 8 parallele Requests abgearbeitet wird, dann ist es eklig.
>
> Und das sind dann halt Sachen, wo eine NetApp durch eine hervorragende udn
> absolut optimierte NFS-Serverimplementierung punkten kann. Darum sind sie
> (IMHO) so schnell im NFS.
>
>> Hatte eigentlich gedacht das ein paar mehr Leute die Mails auf einem
>> externen Storage speichern und nicht lokal auf der Maschine.
>
> Ja, doch, aber da habe ich jetzt nix großes zu jammern... Geht halt und
> 130.000 Accounts sind jetzt auch noch so wenig.
>
> Auf jeden Fall ist mir hier NFS tausendmal lieber als ein Cluster-FS, denn
> das wäre die Alternative, wenn wirklich viele iMAP-Köpfe parallel arbeiten.
>
> a) Cluster-FS sind nicht auf kleine Dateien optimiert
> b) Cluster-FS hat für Absprachen und Cache-Validierung ebenfalls
> (schlimmere?) Latenzen
> c) Ich mag es simple und rock-solid
>
> Also dann lieber NFS und alles ist gut. Wir betreiben auch große Apache-
> Cluster mit ordentlich Bandbreite und Load per NFS. Tut auch prima. Die
> kleinen Nachteile sind IMHO geringer, als wenn man hier eine andere Lösung
> geht wählt. Ist halt immer eine Frage des kleinsten Übels.
>
>
> Peer
>
> P.S.: Ich habe viel versucht darüber zu lernen und zu lesen. Man findet kaum
> was sinnvolles, was nicht an anderer Stelle dementiert wird. Wirklich
> unschön. Für meine obigen Aussagen will ich nicht die Hand dafür ins Feuer
> legen, doch ist das nach vielen Stunden und Tagen Debugging und Analyse die
> hier bei uns im Team vorherschende Meinung/Kenntnis zu der Sache. Einen
> echten NFS-Guru der das mal wirklich auf 110%ige Gewißheit alles klären
> kann, habe ich leider noch nicht gefunden.
>
>

-- 
Mit freundlichem Gruß
     Peer-Joachim Koch
_________________________________________________________
Max-Planck-Institut fuer Biogeochemie
Dr. Peer-Joachim Koch
Hans-Knöll Str.10            Telefon: ++49 3641 57-6705
D-07745 Jena                 Telefax: ++49 3641 57-7705
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : pkoch.vcf
Dateityp    : text/x-vcard
Dateigröße  : 291 bytes
Beschreibung: nicht verfügbar
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20100930/6a3c1880/attachment.vcf>