Lokaler Ordner auf Netzlaufwerk verlangsamt Mailempfang

  • Thunderbird-Version: ESR 10.x
    Betriebssystem + Version: Clients WinXP und Win7
    Kontenart (POP / IMAP): POP3
    Postfachanbieter (z.B. GMX): intern


    Hallo,


    bei unseren Kunden liegen die TB-Profile lokal, aber unter Server-Einstellungen / Lokaler Ordner ist ein Netzlaufwerk angegeben.
    Dieses liegt auf einer Freigabe des Samba-Servers und es technisch sichergestellt, dass es nicht multiuser-zugreifbar ist.
    Über diesen Lokaler Ordner auf dem Netzlaufwerk wird sichergestellt, dass die dort liegenden Daten regelmäßig gesichert werden.


    Bei unseren Tests hat es sich gezeigt, dass bei dieser Konstellation der Mailabruf um ein Vielfaches (Faktor 10 und mehr) langsamer ist, als wenn der Lokale Ordner auf einem lokalen Laufwerk liegt.


    Kennt jemand dieses Verhalten und evtl. die Ursache?
    Gibt es hierfür eine Abhilfe?


    Danke Martin

  • Hallo,


    es ist nicht sinnvoll, das Profil auf diese Art zu "zerstückeln", warum legt ihr nicht das gesamte Profil auf den Server?


    So liegt z.B. die globale Indextabelle lokal vor, die MBoxen aber auf dem Server.

  • Das ist sicherlich eine sinnvolle Möglichkeit.
    Würde sich denn damit auch die Abrufgeschwindigkeit wieder normalisieren, dh. dem entsprechen, als wenn der lokale Ordner auf lokaler Platte liegt?

  • Probiere es aus, ich gehe davon aus.
    Verlagere das Profil und dann starte TB mit dem Profilmanager>Neues Profil erstellen und dann den Profil-Ordner wählen.
    So verbleibt auf dem Rechner in den Anwendungsdaten der Ordner Thunderbird mit der profiles.ini, in welcher der eigentliche Ort des Profils vermerkt ist.


    Siehe auch >Profile verwalten (Anleitungen)
    =>Profil [der Ordner mit den 8_wilden_Buchstaben.default, wobei auch default sonstwie heißen kann, z.B. ghw63k9g.test oder ghw63k9g.MeineMails...
    siehe=> Thunderbird-Menü Hilfe>Information zur Fehlerbehebung>Profilordner>Beinhaltenden Ordner anzeigen und Dateien im Profil kurz erklärt]

  • Danke, die Profilverwaltung ist mir klar, ich werde es morgen mal testen und hier berichten.
    Vielen Dank für den Tipp. :)

  • Wie vorgeschlagen habe ich das Profil auf den Server gelegt, aber das brachte keine Verbesserung. Egal ob das Profil lokal oder auf dem Server liegt, sobald der Ordner unter Server-Einstellungen / Lokaler Ordner auf einem Netzlaufwerk liegt, bricht die Geschwindigkeit um mindestens den Faktor 10 beim Mailabruf ein.


    Dieses bestätigen auf die Protokolle, wenn man über
    set NSPR_LOG_MODULES=pop3:5,timestamp
    set NSPR_LOG_FILE=C:\pop3_lokal.log
    das Logging aktiviert.


    Hat jemand eine Idee, was man weiter untersuchen könnte?


    Danke Martin

  • Wieso hast du denn überhaupt Änderungen in Server-Einstellungen / Lokaler Ordner, wenn du das Profil komplett dort hin legst?

  • Du sagst

    Zitat von "MartinSt"

    sobald der Ordner unter Server-Einstellungen / Lokaler Ordner auf einem Netzlaufwerk liegt

    und das hört sich so an, als hättest du dort Änderungen vorgenommen, also einen abweichenden Pfad eingegeben.

  • Ich fasse mal zusammen:


    Getestet wurde mit einem festen Satz von 8 Mails mit zusammen knapp 60 MB. Gemessen sind jeweils die Zeiten zum Abrufen dieser Mails:
    Profil liegt lokal und Server-Einstellungen / Lokaler Ordner ist ein lokaler Ordner = 12sec.
    Profil liegt im Netz und Server-Einstellungen / Lokaler Ordner ist ein lokaler Ordner = 12sec.


    Profil liegt lokal und Server-Einstellungen / Lokaler Ordner ist ein Netzwerk-Ordner = 140sec.
    Profil liegt im Netz und Server-Einstellungen / Lokaler Ordner ist ein Netzwerk-Ordner = 140sec.


    (Zeiten sind handgestoppt.)


    Die obigen Ergebnisse treten auch mit TB 17 ESR auf und unabhängig davon, ob ein Virenscanner/Firewall aktiv sind.


    Über diesen Lokaler Ordner auf dem Netzlaufwerk soll sichergestellt werden, dass die dort liegenden Daten regelmäßig gesichert werden.


    Kennt jemand dieses Verhalten und evtl. die Ursache?
    Gibt es hierfür eine Abhilfe?

  • Hallo Martin,


    dass es nicht sinnvoll ist (übrigens gerade auch im Hinblick der Datensicherung), ein Profil zu zerteilen, wurde ja oben bereits angesprochen. Hier gibt es einige Berichte von Anwendern, die sich so gehörig die Karten gelegt haben.


    So wenig sinnvoll dieser Ansatz auch ist, erklärt er aber nicht die schlechten Zeiten. Wie verhält sich dieses Netzlaufwerk denn im Vergleich zum lokalen Laufwerk bei ganz normalen Dateioperationen, z.B. beim Kopieren?
    Was genau meinst Du mit "Samba-Server"? Geht es hier um einen "echten" Samba-Server mit Zugriffkontrolle und allem Drum und Dran, oder handelt es sich lediglich um ein paar freigegeben Verzeichnisse auf einem Arbeitsrechner?
    Sind die Antwortzeiten ähnlich schlecht, wenn Du das Profil auf einen Rechner im reinen Windows-Netzwerk legst?


    Gruß


    Susanne

  • Das Kopieren zwischen dem gleichen Windows-Client und dem Server (gleiches Verzeichnis) ist flüssig, 1 GB kopiert in ca 1 Minute.
    Es ist ein echter Linux/Samba-Server inkl. Benutzer und allem was man so hat.


    Einen Windows-Server habe ich so erstmal nicht zur Verfügung und dieses wär auch nicht relevant. Unsere Kunden (die TB nutzen) arbeiten fast ausschließlich mit o.g. Samba-Server.


    Gruß Martin

  • Du benötigst für einen Test keinen Windows Server, eine Freigabe auf einem der Clients sollte genügen. Auf diese Weise könntest Du herausbekommen, ob die schlechte Performance durch den Samba-Server bzw. dessen Konfiguration verursacht wird oder durch den TB bzw. dessen Art des I/O. Es kann einen Unterschied ausmachen, ob ein sehr großes File transferiert wird oder ob viele kleine Zugriffe auf mehrere Files erfolgen. Der I/O des TB wird wohl eher dem zweiten Fall entsprechen.


    Eine weitere Frage wäre, ob sich die xp- und W7-Clients gleich verhalten. Es gibt da offenbar bekannte Unterschiede, siehe hier.

  • Hallo Martin,


    na dann lag ich mit der These, dass es an den vielen, kleinen I/O liegen könnte, ja nicht schlecht. Und wie es aussieht wird an einem Fix gearbeitet (auch wenn der letzte wohl nicht ganz gelang ;-)).
    Ich weiß nicht ob es etwas bringt, aber als Interimslösung könntest Du Async-I/O- aktivieren und ein wenig mit den Parametern


    Code
    1. min receivefile size
    2. aio write size
    3. aio read size
    4. use sendfile


    experimentieren. Insbesondere die beiden ersten können vielleicht etwas Performancegewinn bringen. Auch die Socket-Options können vielleicht etwas bringen, aber dazu braucht es wohl einen Netzwerkspezialisten.
    Ganz Mutige trauen sich auch ein write behind, aber den halte ich für viel zu riskant.


    Gruß


    Susanne

  • Nabend,


    mutig ja und auch selber Entwickler. ;)
    Wie und wo wirken die von dir genannten Parameter? in der TB-Config?


    Gruß Martin

  • Hallo Martin,


    nein, das sind Parameter in der /etc/samba/smb.conf.


    Bei allem Mut, mit dem write behind würde ich nicht spielen. Es bewirkt, dass Samba nicht auf ein "acknowledged" wartet sondern sofort einen erfolgreichen Schreibzugriff zurückmeldet, auch wenn dieser noch gar nicht beendet ist. Das geht in der Regel gut. Doch sollte beim Schreiben ein Fehler auftreten, bemerkt der Client das nicht. Für den war der Vorgang ja bereits erfolgreich.


    Mein gesundes Halbwissen zu den Parametern:


    Mit aio write size bzw. aio read size kannst Du einstellen, ab welcher Größe Samba asynchrones I/O verwenden soll. Das funktioniert aber nur, solange Du keinen write cache verwendest. Der wäre übrigens auch eine mögliche Tuning-Option, allerdings vermute ich, dass dieser Cache in erster Linie bei großen Files Wirkung zeigt und weniger bei vielen kleinen, um die es hier geht.


    Sendfile bringt meines Wissens nur etwas, wenn es konkurrierende Schreibzugriffe gibt. Wenn Du use sendfile=yes setzt, verwendet Samba die sendfile-routine. Das kann spürbaren Performance-Gewinn bringen, wenn die Clients das Opportunistic Locking (oplocks) verwenden, um Dateien zu sperren. Der Client teilt dabei dem Samba-Server mit, dass er nicht der alleinige Schreiber ist und eine lokale Kopie der veränderten Datei bereit hält. Das ermöglicht es Samba, Dateien nicht komplett zu sperren. Samba kann dann den Schreibzugriff per break unterbrechen und einem anderen Client kurzeitig Zugriff erlauben.
    Opportunistic Locking ist unter W7 meines Wissen per default möglich. Für xp weiß ich es nicht. Aber ich glaube eh nicht, dass sendfile in Deinem Fall von Nutzen sein wird, weil es eher nicht um konkurrierende Zugriffe geht. Aber, wer weiß ... .


    Mit der min receivefile size kannst Du sogenannte "zero-copy writes" ermöglichen. Dabei werden die Datenmengen ab einer bestimmte Größe direkt in den buffer cache des Filesystems geschrieben. Der Wert min receivefile size=0 ist die Standardeinstellung und schaltet das Feature ab.


    Wie geschrieben sind das Parameter, mit den es sich vielleicht in einer Testumgebung zu spielen lohnt. Ich kann Dir keine Empfehlungen für konkrete Werte geben. Sie hängen doch sehr von der jeweiligen Situation ab, fallen also in den Bereich des Tuning.
    Als ich mir vor ein paar Jahren zum Spielen einen Samba-Server aufgesetzt habe, hat mir das Buch "Samba 2" von O'Reilly sehr geholfen. Es ist frei im Internet verfügbar ist.



    Gruß


    Susanne

  • Hallo Liebe TBProfis,


    ich möchte diesen Thread noch mal aufgreifen, denn ich habe genau das gleiche Problem wie oben beschrieben. Auch wir wollten ein lokales Archiv zur Archivierung aller emails nutzen. Diesee lokaler Ordner liegt im Netz auf einer smb Freigabe, wie in den vorigen Beiträgen beschrieben. Aucg wir beobachten die Verlangsamung der Mailabrufe um den bes hriebenen Faktor.


    Ist inzwischen bekannt, wo bei diesem Problem anzusetzen ist?


    Gruß nospero