Mozilla Thunderbird mag nicht mit Samba spielen

Dalai

Grand Admiral Special
Mitglied seit
14.06.2004
Beiträge
7.420
Renomée
262
Standort
Meiningen, Thüringen
Hey Leute und (Besser)wisser :),

in der Firma bei uns wurde zu Weihnachten von Thunderbird 2.0 auf Thunderbird 24.x umgestellt, um unter anderem die Integration von Lightning zu haben. Letztlich hat sich herausgestellt, dass die Mitarbeiter dieses Weihnachtsgeschenk nicht mögen - und zwar völlig zu recht.

Denn das Kopieren und Verschieben von Mails von einem Ordner in einen anderen geht unglaublich lahm, um Faktor 10 bis 20 :o langsamer als es eigentlich sollte! Lahm sind die Operationen dann, wenn das Profil auf einem Samba liegt, nicht bei lokalem Profil oder auf der Freigabe eines Windows-Rechners/-Servers. Keinen Einfluss auf die Sache haben Dinge wie Cache (im Thunderbird) und Nachrichtenindizierung.

Ein paar Zahlen als Anhaltspunkt, die jeweils mit einem Stock Thunderbird gemessen wurden:
Code:
Simpler Dateitransfer einer Datei mit 2 GiB auf Linux-Server:   ~50 bis 60 MB/s lesend, ~60 bis 70 MB/s schreibend

Thunderbird 2.0 portable
6 Mails mit ~53 MB

Profil lokal:                 ~13 Sekunden
Profil auf Windows-Server:    ~16 Sekunden
Profil auf Linux-Server:   ~11-21 Sekunden

Thunderbird 24.6.0 portable
Thunderbird 38.7.2 portable
Thunderbird 45.1.0 portable
6 Mails mit ~53 MB

Profil lokal:                 ~6-7 Sekunden
Profil auf Windows-Server:    ~7-8 Sekunden
Profil auf Linux-Server:  ~200-210 Sekunden  (~90-100 Sekunden unter Win7)
Die Operationen sind dabei immer dieselben, die Mails sind exakt dieselben. Das Client-OS hat einen gewissen Einfluss, wie man anhand der letzten Zeile sehen kann. Trotzdem sind die 90 Sekunden für das Verschieben von 6 popeligen Mails absolut indiskutabel!

Wir wissen mittlerweile, dass wir damit nicht alleine sind. Diese beiden Mozilla-Bugreports[1] deuten aber darauf hin, dass dieses (oder möglicherweise doch ein anderes?) Problem inzwischen gelöst sein soll. Die Zeitangaben oben sprechen eindeutig dagegen. Wir haben natürlich verschiedene Samba-Optionen ausprobiert (socket options, use sendfile, max xmit, min receivefile size, aio read/write size, write cache size), aber am Grundproblem im Thunderbird ändern diese allesamt nichts. Der Samba selbst ist ja auch schnell genug, wie die erste Zeile der Zahlen oben zeigt.

Fragen:
Hat jemand eine Idee, wo man ansetzen kann? Hat damit schon einmal jemand zu tun gehabt? Weiß jemand, woran es liegt? Oder noch besser: eine Lösung?

[1]
https://bugzilla.mozilla.org/show_bug.cgi?id=539389
https://bugzilla.mozilla.org/show_bug.cgi?id=589798

Crosspost im ThinkPad-Forum

MfG Dalai
 
Zuletzt bearbeitet:
Wie sind die Oplock-Settings von Samba?

--- Update ---

Und von welcher Samba-Version reden wir überhaupt?
 
Welche Einstellungen meinst du genau?
Code:
$ testparm -sv | grep -i oplock

        kernel oplocks = Yes
        oplock break wait time = 0
        veto oplock files =
        fake oplocks = No
        oplocks = Yes
        level2 oplocks = Yes
        oplock contention limit = 2
Samba ist übrigens Version 3.6 (auf Ubuntu 12.04).

MfG Dalai
 
Man könnte probieren, die Oplocks zu deaktivieren, d.h. auf der Share

Code:
oplocks = no
level2 oplocks = no
locking = no
strict locking = no
share modes = no

Andererseits schreibt TB sehr oft sehr viele kleine Dateien; da könnte man auch mal

Code:
min receivefile size
aio write size
aio read size
use sendfile

anschauen und mal damit spielen. V.a. "min receivefile size" ist meines Wissens per default auf 0 gesetzt und damit aus. Ich weiß jetzt aber nicht, ob das schon in 3.6 drin war.

Was spricht eigentlich gegen 4.2? Das könnte man sich für 12.04 von dort holen: https://portal.enterprisesamba.com/ (kostet ab Samba 4.3 was, aber 4.2 bekommt man noch so).
 
Man könnte probieren, die Oplocks zu deaktivieren
Werden wir mal testen.

Andererseits schreibt TB sehr oft sehr viele kleine Dateien
Nö, nicht in diesem Fall. Der Gag ist ja, dass man während des Verschiebens genug Zeit hat, der Datei (die den Zielordner enthält) beim Wachsen zuzuschauen. Thunderbird schreibt also nicht viele kleine Dateien sondern viele kleine Häppchen in diese Datei. Offenbar schreiben die neueren TB-Versionen wesentlich kleinere Häppchen als die 2er.

da könnte man auch mal

Code:
min receivefile size
aio write size
aio read size
use sendfile

anschauen und mal damit spielen.
Been there, done that, wie bereits im OP steht.

Was spricht eigentlich gegen 4.2?
Naja, vor einem solchen Austausch muss schon sichergestellt sein, dass dieses Problem gelöst wird, und sich vor allem keine neuen anderen auftun. Wir reden hier schließlich von einer Produktivumgebung. Deswegen auch dieser Thread, um erstmal ein bisschen zu ermitteln, der Problemursache auf die Spur zu kommen

MfG Dalai
 
Zuletzt bearbeitet:
Been there, done that, wie bereits im OP steht.
Sorry, überlesen.

Naja, vor einem solchen Austausch muss schon sichergestellt sein, dass dieses Problem gelöst wird, und sich vor allem keine neuen anderen auftun. Wir reden hier schließlich von einer Produktivumgebung. Deswegen auch dieser Thread, um erstmal ein bisschen zu ermitteln, der Problemursache auf die Spur zu kommen
Testumgebung mit ein paar VMs aufsetzen? ;D

Ich weiß aber schon, wie nervig das sein kann. Letztlich habe ich auch in einem Fall extra mit Etherreal ein Verhalten auf einem Original-Windows-Share mit einem von Samba verglichen und an die Samba-Mailing-Liste gepostet, zusammen mit Samba-Logs mit der höchsten Detailstufe.

Aber das heißt leider nicht, dass die Mailing-Liste da helfen (oder Einträge im Bugtracker verfolgt werden) , leider. So'ne richtig hilfsbereite Community habe ich bei Samba nie vorgefunden. :P
 
Man könnte probieren, die Oplocks zu deaktivieren, d.h. auf der Share

Code:
oplocks = no
level2 oplocks = no
locking = no
strict locking = no
share modes = no
Das macht es noch schlimmer, die Wartezeiten steigen weiter an, auch im Thunderbird 2.0; dort aber nicht so stark wie im 38er. Die Option share modes habe ich allerdings ausgelassen, weil sie eineseits als deprecated markiert ist und andererseits in der Manpage vom Abschalten abgeraten wird.

Noch ein Detail: Während der Wartezeit im Thunderbird 24+ ist die Kernellast auf dem Windows-Client massiv sichtbar, liegt bei 30 bis 40 Prozent (natürlich abhängig von der CPU), die Netzwerklast dümpelt aber bei unter 2 Prozent herum! Im Thunderbird 2.0 hingegen ist die Kernellast kaum sichtbar (unter 2%), die Netzwerklast liegt bei 6-7%.

Ich ziehe gerade die Installations-CD von Ubuntu 16.04, damit ich in den nächsten Tagen mal in eine weitere VM mit einem neueren Samba aufsetzen kann. Ich befürchte nur, dass es dort nicht besser wird. Samba ist ja nur einer der Faktoren, das Zusammenspiel mit Thunderbird ist ja der Knackpunkt.

MfG Dalai
 
hat zwar jetzt nicht direkt was mit Deinem Problem zu tun, aber:
Thunderbird Profile funktionieren auch auf NFS nicht ordentlich. Egal ob V3 oder V4.
Ebenso wegen dem "nur kleine Häppchen" Problem.

Ich konnte bisher auch keine Lösung finden (auch auf 16.04 nicht)
 
Ich hab heute in einer VM Ubuntu 16.04 installiert, das Samba 4.3 mitbringt, und dort sind die Zeiten akzeptabel, liegen bei ~10 Sekunden :o. Als ich die Zeiten sah, hab ich erstmal Bauklötze gestaunt, weil ich das nicht erwartet habe. Ernüchtert wurde ich dann durch den Gegentest mit einem XP-Client, denn dort waren die Zeiten lahm "wie üblich". Daraus schlussfolgerte ich, dass es irgendeine (Standard-)Einstellung ist, die im neuen Samba (anders) gesetzt ist. Nach einem Vergleich der Optionen bin ich bei der Protokollversion hängengeblieben und habe diese Option im Samba 3.6 probiert:
Code:
max protocol = SMB2
Und siehe da: auch dort sind die Zeiten akzeptabel, liegen ebenfalls um 10 Sekunden. Ein Gegentest bei Samba 4.3 mit Limitierung auf die alte Protokollversion
Code:
max protocol = NT1
wurde dann auch prompt - nach einem Relogin im Win7-Client - mit lahmem Verschieben "belohnt"; wieder um die 100 Sekunden.

Das bedeutet, dass SMB2 irgendwelche Optimierungen beinhaltet, die das Problem nicht erkennen lassen bzw. besser kaschieren können. Wir werden das auf dem Produktivsystem mal freischalten und testen, ob das funktioniert (wovon ich ausgehe) und ob es irgendwelche Probleme damit gibt (wenn ein Mitarbeiter schreit ;D).

Bleibt als Fazit, dass die neuen Thunderbirds da irgendein verdammt schlechtes Verfahren und/oder einen schlechten Algorithmus benutzen, denn auch bei lokalem Profil ist die CPU-Last beim Verschieben von Mails massiv höher als beim 2er Thunderbird; bei letzterem ist da kaum Last zu erkennen. Offensichtlich wirkt sich das aber "nur" auf alten Windows-Clients, alten Sambas und NFS aus.

Vielleicht wäre es für Tom eine Lösung, einen Samba statt NFS zu nutzen, so dass sowohl die Clients als auch die Server SMB2 oder höher sprechen und damit das Problem kaschieren *lol*

MfG Dalai
 
@ghostadmin: Lokale Profile in einer Domäne (mit servergespeicherten Profilen)? Nö, ist nicht so wirklich sinnvoll.
 
Ist doch nur Thunderbird, wo ist der große Vorteil?
Mails am PC zusätzlich zu speichern ist auch nicht ganz verkehrt.
 
IMAP-Server aufsetzen und die Mails auf dem Server lassen, dann ist das lokale Konto eh' Wegwerf-Ware.

Wobei ich sagen muss, dass mich meine Faulheit auch dran hindert, ein ähnliches Setup mit Thunderbird, Samba4-DC und Roaming Profiles auf IMAP umzusetzen. :P
 
Ist doch nur Thunderbird, wo ist der große Vorteil?
Muss ich dir jetzt wirklich die Vorteile von Roaming Profiles erklären?

Mails am PC zusätzlich zu speichern ist auch nicht ganz verkehrt.
Und das synchronisierst du wann und in einer sinnvollen Zeit, bei großen Mailprofilen mit 1 GiB und mehr?

MfG Dalai
 
Zurück
Oben Unten