FreeNAS: SMB-Freigabe extrem langsam

agrajag

Active Member
Moin moin. Ich spiele gerade mit Freenas 11.1 auf einem 4-Kern-Xeon-System mit 16GB ECC-RAM. Derzeit hab ich die Platten noch einzeln jeweils als Pool laufen. Vorweg: iperf bescheinigt mir hier 913Mbits/s zwischen dem Macbook Pro und dem FreeNAS. Das Netzwerk kann man also wohl als Fehlerursache ausschliessen.

Wenn ich Daten zum/vom NAS transferiere schwankt die Geschwindigkeit sehr stark. Mehrere Sekunden nur wenige 10kByte/s, dann wieder ein paar Sekunden gerne auch mal >50MBs. Aber unter dem Strich sind es locker <10MBytes/s. Und das bei großen Dateien wie Videos. Verzeichnisse öffnen dauert auch viele Sekunden. Bis ein Kopiervorgang startet dauert es Minuten. Wenn er startet kann es sein, daß es über Minuten nicht mal ansatzweise in Richtung 1MBytes/s geht.

Mir ist aufgefallen, daß der smbd-Prozess sich mehr im "zio->i"-State befindet als in anderen. Die CPUs langweilen sich zu Tode. Der System-Load liegt aber bei >300. Welche Ressource ist da so knapp? Wo kann ich ansetzen?

Anmerkung: ich bin immer noch ein reiner BSD-Neuling (hatte bislang zuwenig Zeit). Ich hab eher rudimentäre Erfahrungen in der Shell (OSX). Also langsam mit den jungen Pferden. :-)
 
Das hatte ich auch kurz in Verdacht, aber ich bin schon längst auf 10.13 (was jetzt nicht unbedingt besser sein muß ;))

Ich hab FreeNAS gestern abend komplett zurückgesetzt (factory default in der Konsole). Die Verzeichnisse lassen sich jetzt wieder öffnen, als wären sie lokal. Der Datentransfer ist nun auch deutlich schneller, wenn auch, mit ~10-15MB/s, doch sehr weit unter den Erwartungen (ich erwarte da doch eher min. 70MB/s). Bis der Kopiervorgang startet (mit zwei Video-Dateien getestet) dauert es mit mehreren Sekunden auch sehr deutlich zu lang.

Jetzt hält smbd gerade die Füße still, aber eben hat es über eine Stunde lang rund 50% CPU gefressen (pendelte immer zwischen 40-60%). Es war auch wieder deutlich länger im "zio->i"-Zustand als in anderen. Es ist aber nicht mehr ganz so schlimm wie gestern.

Den System-Load hab ich seitdem auch längst nicht mehr so hoch gesehen (bestenfalls 10-20).
 
Hast du die Möglichkeit, einen Windows Client zum testen zu verwenden oder halt eine Linux-Live CD?
 
Evtl. musst Du noch die IP und den dazugehoerigen hostname des FreeNAS in die /etc/hosts Datei auf dem Macbook eintragen. Nur so ins blaue geraten, aber ich hatte mal einen aehnlichen Fall.
 
Ich hatte bis eben einen scrub auf einem Laufwerk. Die seitdem geht der smdb nicht mehr in den Zustand "zio->i". Wirkt sich ein scrub auf einem Laufwerk so sehr auf die Performance aller Laufwerke/Pools aus? Warum? Kann man den scrub-Vorgang irgendwie (deutlich) niedriger priorisieren?

Mit etwas über 30MB/s liege ich aber immer noch weit unter den Möglichkeiten. :-/ smdb ist beim Transfer von Video-Dateien (NAS -> MBP mit USB3-PLatte) bei fast 80% CPU. Wenn einfach nur die Shares (4) geöffnet sind, liegt smbd imme rnoch bei bis 50-60%. Da stimmt also noch etwas nicht.
 
Ich hab nochmal schnell nachgeschaut und getestst: die USB3-Platte wird auch wirklich im USB3-Modus betrieben (5G-Modus) und sollte um 70MB/s dauerhaft sequenziell schreiben können. Das ist auch nicht die Bremse für den lahmen Transfer.
 
smbd liegt bei 0% CPU, wenn keine Shares gemountet sind. Worfür benötigt es 60% CPU, nur weil ein Client Shares offen hält?
 
Kann das Auswirkungen auf die Geschwindigkeit haben?!?

Ob es Auswirkungen auf die Uebertragungsgeschwindigkeit selbst haben kann, weiss ich leider nicht. Aber wenn die firewall z.B. den DNS oder andere notwendige Dienste im Netzwerk blockiert, kann es Auswirkungen auf die Latenz der Anfragen und Antworten haben. Ich kenne mich mit smb leider nicht aus, hatte aber so einen Fall schon beim debuggen eines grossen Messenetzwerks im Zusammenhang mit MySQL.
 
Ah, ok. Firewalls sind hier definitiv nicht im Spiel. Personal Firewalls benutze ich nicht und auf dem FreeNAS läuft (meines Wissens nach) keine.

Ich hab eben mal den Tipp mit Windows ausprobiert: ich komme stabil auf 102MB/s NAS->Win auf interne SSD. smdb liegt bei 22% CPU. Wenn ich in Windows die 4 Shares offen habe (je in einem Explorer-Fenster) liegt smbd bei 0%.

Bei NAS->OSX auf interne SSD komme ich auf <70MB/s. smdb liegt dabei bei rund 80% CPU. Bei 4 geöffneten Shares beim Nichtstun auch wieder beruhigt und liegt wieder bei 0%.

Was macht OSX da nur? Vor allem was macht es, um beim Transfer den smdb zu so einer CPU-Auslastung zu treiben?
 
Das reine offen halten der 4 Shares provoziert jetzt keine erhöhte CPU-Last mehr. Warum auch immer. Ist hier irgendein Verzeichnis-Caching oder ähnliches im Spiel?

Die CPU-Last beim Trans liegt übrigens sogar bei >90%. :-(

Ich verstehe das nicht und es ist extrem unbefriedigend? Aber immerhin geht es schonmal >>50MB/s – zumindest bei großen Dateien. Mit kleinen hab ich noch nicht getestet.

Aber es scheint mir so, als ob der Sündenbock bei Apple zu suchen ist, oder? Ich kann also FreeNAS-seitig nichts machen.
 
Danke danke danke… das war der entscheidene Hinweis. :-)

Man muß nur in die Datei /etc/nsmb.conf (ggf. muß sie erst angelegt werden)

[default]
signing_required=no

eintragen und die Shares neu öffnen. Dann hinkt OSX zwar immer noch ein gutes Stück hinter Windows hinterher, aber 75-85MB/s sind schon das was ich haben wollte. Und smbd braucht nun auch nur noch 25-30% CPU. :-)

Mensch, Apple… wieso gibt es für sowas keine Option in den Systemeinstellungen? Statt dessen wird es einfach aktiviert und nicht wirklich kommuniziert und das Netz fragt sich, warum deren SMB so scheisse ist. *klatschhandvorkopf*



Bliebe noch die Frage: lässt sich das Scrubbing renicen, so daß es sich in den Hintergrund drängen lässt, wenn Zugriffe auf die Platte passieren? Ansonsten soll es mit maximaler Geschwindigkeit scrubben.
 
Bliebe noch die Frage: lässt sich das Scrubbing renicen, so daß es sich in den Hintergrund drängen lässt, wenn Zugriffe auf die Platte passieren? Ansonsten soll es mit maximaler Geschwindigkeit scrubben.
warum willst du denn scrubben? das ist doch eher ein Ausnahmezustand, dem ich gar keine Beachtung schenke. Also, wenn ich das mal brauche, dann ist es ja schon ernst und ein Ausnahmezustand, der auch so kommuniziert werden kann.
 
Das Problem ist, daß das NAS nicht 24/7 laufen soll, sondern eher nur bei Bedarf über ein paar Stunden. Dienste, die 24/7 laufen sollen (24h-Instanz von Resilio Sync, AirPlay/Chromcast-Server, FTP-Freigabe für den Netzwerk-ADF-Scanner, Kodi als Musik-Spieler, der über eine Kodi-App fernbedient wird), laufen hier auf einem headless Mac mini, der deutlich Energiesparender ist.

Und hier wäre es extrem nervig, wenn der Server aufgeweckt wird und als erstes das ZFS beginnt zu scrubben, was bei 3TB-Platten nun doch etwas länger dauert, und man die Netzwerkfreigaben in der Zeit kaum benutzen kann. Ok, ich kann ja nochmal testen, wie sich das SMB beim Scrubben nach der SMB-Client-Änderung verhält. Vielleicht ist es ja dann etwas erträglicher. Aber ich bin da wenig zuversichtlich, da ja der "zio->i"-State hier ein dominierender Faktor war, was ja wohl bedeutet, daß ständig auf ZFS gewartet wurde.
 
ZFS macht von sich aus keinen automatischen "Scrub" der Pools. Ich vermute hier einen Cronjob. Ich kenne FreeNAS aber zu wenig, um dir dabei zu helfen.
Naja, klar. Das läuft per Cronjob. Und alle paar Wochen sollte man sich da ja mal gönnen. Aber aufgrund der geringen Power-On-Zeiten würde das dann immer in die Zeiten fallen, wo man auch wirklich auf die Kiste zugreifen wollen würde. Und einen Scheduler, der die Kiste für diesen Zweck in der Nacht wecken könnte, hab ich nicht bemerkt.
 
Ich lese immer etwas von 1x im Monat. Ich würde vermutlich eher alle 2 Monate scrubben. Aber das hab ich mir noch nicht fest überlegt. Ich bin für Anregungen offen. :-)
 
und ich muss mich gleich wieder zurück nehmen. Es sprudelt oft nur so aus purer Begeisterung aus mir heraus, aber ich habe in diesem Forum gelernt, dass andere Leute über viele Dinge sehr viel besser Bescheid wissen und ich lieber mal etwas Zurückhaltung über muss.

Also fachlich unqualifiziert nur meine eigene Erfahrung: mein FreeBSD Server mit einem (frühen) ZFS ist knappe zehn Jahre alt und im 24x7 Betrieb und hat keine dutzend scrubs mitgemacht. In der Regel nach Problemen auf Grund von Festplatten-Tod und/oder Stromausfällen.
Ich weiß nicht, ob das gut ist oder falsch, aber es geht jedenfalls vollkommen ohne scrub auf lange Zeit und ich bemerke keine Nachteile.
 
Ein 'zpool scrub' liest im Prinzip einmal alle Daten auf dem jeweiligen Pool und schaut anhand der zugehörigen Prüfsummen nach, ob sie noch korrekt gespeichert sind. Sind sie es nicht mehr, ist es ein Hinweis auf Fehler im System, z.B. durch sterbende Platten oder den Evergreen kaputter Kabel. Aber solange man seinem System vertraut, und wenn man das nicht tut sollte man vielleicht keine wichtigen Daten drauf speichern, ist so ein 'zpool scrub' eigentlich nicht häufig notwendig. Und oft auch nicht wirklich zweckmäßig, auf großen Pools mit ständiger IO-Last können sie auch schon mal Tage dauern. Ich halte es wie @pit234a und scrubbe (tolles Wort) nur, wenn ich:
  • Eine Notwenigkeit sehe, z.B. nach ATA-Fehlern im Systemlog.
  • Aus Gewohnheit einmal nach Hauptversionsupdates des Betriebssystems.
Das ist dann im Schnitt in etwa so einmal im Jahr. Für wesentlich wichtiger als Fragen wie oft man scrubben soll halte ich dann auch, dass man regelmäßig Backups schreibt. Denn Festplatten sind Arschlöcher und sterben nur selten mit Anstand.
 
Zurück
Oben