Datei/Verzeichnis Zugriff sehr langsam!

[connorxxl]

Guten Morgen miteinander!

Ich habe hier ab und zu mitgelesen. Ich habe 8 Ironwolf 10tb in einer 2415+. Bisher keine Probleme. Die Platten sind deutlich lauter als die vorigen RED 4tb, das ist aber auch nicht schwer, die REDs waren nicht zu hören. (Eine 10tb Ironwolf überstand den initialen Burn-in Test nicht, aber das kann passieren. Wurde umgetauscht.)
Meine Erfahrungen sind bisher gut.

Bezüglich der Reaktionszeit der DS hatte ich am Anfang auch ein wenig Probleme, das hat sich allerdings mit Mac OS X 10.13 deutlich verbessert (reiner Mac-Haushalt). Greife auf das NAS allerdings auch mit CIFS zu.

Auf der DS laufen:
- Mehrere Docker-Container, mit ständigem Zugriff auf die Platten
- Cloud Sync
- NFS Data Store für kleine VMs (ESXi 6.5.0 auf einem anderen Server)

Bei Fragen gerne schreiben.

Wünsche einen schönen Montag!

Gruss,

Christian

 

[SoniX]

Ich glaube ich bin dem Problem soeben ein Stück näher gekommen.
Und ich muss mich wohl Entschuldigen in Bezug auf die Ironwolfs.

Ich bin eher zufällig auf einen alten Thread zu DSM 5.2 beta (Ja, 5.2 ist richtig) gestossen wo Performanceprobleme auftraten.
Da wurde versucht das Problem einzukreisen. Es trat verstärkt bei großen Dateien auf (Ich habe ja auch große Dateien).
Manchen half es sie SMB Verschlüsselung zu deaktivieren, manchen half es auf SMB1 zu wechseln, andere haben zu SMB3 gewechselt.

Ein Vorschlag aus dem Thread hat bei mir eingeschlagen: Im DSM den SMB Cache löschen. Auf den Button gedrückt und sofort war der Netzwerkzugriff schnell.
Also nicht nur die ewigen Verzögerungen weg wenn ich die Netzwerkverbindung öffne, nein es gibt überhaupt keine Verzögerungen mehr.
Ich bekomme im Moment des draufklickens sofort meine Netzwerkumgebung angezeigt.

WOOOHOOO !!!!! :-D :-D

Ich halte es zwar für möglich dass dieses Problem zurückkommen könnte, aber dann weiß ich wo ich weitersuchen muss.
Dann werde ich mich mit den SMB Versionen, SMB Verschlüsselung, SMB Locking etc beschäftigen.

Synology hatte daraufhin auch einen Patch veröffentlicht der bei den meisten, aber nicht bei allen Usern Abhilfe schuf.

Habe wohl den seltenen Fall dieses Problem noch mit DSM 6 zu haben... ^^

Dass dieses Problem verstärkt bei großen Dateien auftritt erklärt auch wieso es bei meiner anderen Diskstation mit den gleichen Einstellungen nicht auftritt.
Dort habe ich zwar viele, aber maximal 4GB große Dateien (Alles größere wird des Handling wegen gesplittet).

Ich hoffe ich habe das Problem damit endlich beseitigt. Melde mich aber falls es Neuigkeiten gibt (und auch wenn das Problem jetzt wirklich fern bleibt).

Ich danke euch allen sehr für eure Mithilfe! Ihr habt wirklich viel Zeit investiert und habe mir sehr geholfen.

Danke sehr!

 

[SoniX]

Nur der Vollständigkeit halber möchte ich hinzufügen:

Das Problem liegt und lag ganz klar an den Ironwolf Platten.
Wie sich inzwischen herausgestellt hat ist bei diesen der Cache deaktiviert.
Es gab zwar einige Updates und bei einigen Modellen der Ironwolfs wurde der Cache nachträglich doch wieder aktiviert; bei meinen jedoch nicht.

Das erklärt auch die starken Lastausschläge und die langsame Auflistung, die mal mehr und mal weniger auftritt, je nachdem ob die Diskstation die Daten gerade im RAM-Cache hat oder nicht.

Ich habe auch bis heute das Problem dass ich keine zwei parallelen Dateioperationen machen kann.
Wenn ich zB ein Video zum ansehen starten möchte, im Hintergrund aber gerade eines kopiert, dann sehe ich solange nichts vom Video bis der Kopiervorgang im Hintergrund abgeschlossen ist. Das ist absolute Grütze... da gucke ich dann ein paar Minuten auf ein leeres Videofenster. Durch den fehlenden Cache gehen ja auch noch weitere Features verloren wie zB NCQ.

Seagate hat hier schlicht fehlerhafte Platten verkauft und als Schutzmaßnahme den Cache deaktiviert.

Mein Ausflug in die Seagatewelt ist beendet. Die kamen mir damals nicht ins Haus (nach schlechten Erfahrungen damals) und kommen mir auch nicht wieder ins Haus (nach den schlechten Erfahrungen jetzt).
Der billige Preis (über 100€ weniger als die Reds) haben schon einen Grund.

 

[peterhoffmann]

Danke für dein Feedback und die klaren Worte.

Seagate hat hier schlicht fehlerhafte Platten verkauft und als Schutzmaßnahme den Cache deaktiviert.

..., sowie hat Synology dem Kunden weisgemacht, dass die Ausschaltung des Caches überhaupt keine Performanceeinbußen nach sich zieht.
Wie du festgestellt hast, kann man diese "nicht vorhandenen" Performanceeinbußen schon bei einem einfachen parallelen Dateizugriff nachstellen.

 

[synfor]

Es war aber Synology, die den Cache deaktiviert haben und die dem User weismachen wollten, dass der abgeschaltete Cache keine Performanceeinbußen nach sich zieht.

 

[peterhoffmann]

Es war aber Synology

Stimmt, soviel Genauigkeit muss sein. Es war Synology, die dieses Märchen erzählt haben.

Ich habe das oben im Beitrag korrigiert.

 

[adamp]

Absolut. Ohne Cache ist das Szenario absolut richtig. Die Performance von gleichzeitigen Zugriffen (Lesend/Schreibend) gegen dann gegen null

 

[adamp]

Ich habe gerade ggf eine Lösung für das Problem.

Ich habe 3 x ST10000VN0004-2GS11L und 1 x ST10000VN0004-1ZD101. Da die 1ZD101 als letzte hDD in die DS kam, habe ich da auf den Cache nicht geachtet und dachte, dass der Cache wie bei den anderen AN ist. Durch den Thread schaute ich nach und sah dass er nur bei dieser HDD deaktiviert war. Da meien DS416play im RAID 5 lief, hat sich der Performance Nachteil im Rahmen gehalten. Trotzdem bremst ein deaktivierter Cache massiv gleichzeitige Schreib/Lese Zugriffe.

Darauf habe ich diesen Thread entdeckt: https://community.synology.com/enu/forum/6/post/122610?page=4&sort=oldest

https://apps1.seagate.com/downloads/certificate.html?key=1237891795995

Dort ist der Fehler bekannt, es ist wohl ein Bug in der FW der betreffenden Ironwolf Version. Man gibt die Seriennummer der HDD auf der Seagate Seite ein und es wird nach einer neuen FW gesucht. Das funktioniert nicht. Bei mir wurde keine neuere FW gefunden. Die Macke ist auch bekannt.

Ein Seagate MOD hat einen entsprechenden Download Link für die PRO / NON PRO Ironwolf eingestellt. Dort kann man SEA CHEST inkl. der aktuellen FW SC61 NUR für die 1ZD101 herunterziehen. Das Update sollte auch unter Windows gehen. Davon wird aber abgeraten. Daher mit dem beigefügten Win Tool einen Linux Boot Stick erstellen, die FW (LOD Datei) ins Hauptverzeichnis kopieren und dann die HDD über SATA / ESATA an einen Rechner anklemmen.
Vom Stick booten und dann sollte man die Seagate HDD inkl. FW Version auch sehen.

Die FW mit dem Befehl SeaChest_Firmware -d /dev/sg2 --downloadFW fwfilename aktualisieren.

HDD in die Syno hineinstecken und sich sofort an der SC61 FW inkl Write Cache AN erfreuen, natürlich mit voller Performance.
Die FW ist nur die besagte HDD, meine anderen Versionen sind weiter auf SC60 und bekommen kein FW Update.

Daten gehen nicht verloren, mein RAID5 Array ist weiterhin vorhanden. Die HDD kratzt jetzt auch gleich etwas weniger.

Natürlich muss ich zugeben, dass der Weg etwas steinig ist und ich mich wundere warum Seagate nicht einfach ein kleines FW Tool herausgebracht hat.

Aber es funzt !

 

[SchmiererKai]

Der Thread ist schon ein paar Tage alt. Trotzdem würde ich gerne das Thema wieder aufgreifen:

Folgende Situation:

Ich habe eine DS720+ als DM-Controller in einem kleinen Firmen Netzwerk.
2x 4TB Seagate Iron ST400VN008-2DR166.
2x 512 Sandisk Extreme Pro als Lese/Schreib Cache.

Hauptsächlich greifen diverse CAD Rechner auf den Server zu. Wenn größere Projekte geladen werden muss die Software auf den Clients bis zu 2000 Dateien nacheinander lesen und darstellen.
Leider ist die Zugriffszeit auf die einzelnen Dateien im Vergleich zu einem 2008er Windows Server um ca. 50% langsamer.

Bspw. Öffnen Projekt A 4620 Dateien (Test mehrmals durchgeführt)
Dauer früher 1:40min
Dauer DS720+ 2:40min

Anbei ein Bild eines Benchmarks eines Laufwerks. Es fällt auf das die Leselatenz bei 20ms liegt.


Folgende Aufnahme noch aus dem Resourcenmonitor
Detailanzeige Laufwerke:


Arbeitet der Cache richtig?

und Prozessor bzw. Netzwerk.


Das Performance Problem besteht nur bei vielen kleinen lese Vorgängen.

Hat jemand vielleicht einen rat wie ich das Problem lösen könnte?

 

[synfor]

Lokal arbeiten.

 

[SchmiererKai]

Naja das würde das Problem wohl wahrhaftig beheben allerdings ist das keine Option.

Der Schreib Cache ist laut Konfiguration aktiviert.

 

[synfor]

Beim Arbeiten über das Netzwerk schlagen halt die höheren Latenzen zu. Beim Zugriff auf eine Hand voll großer Dateien merkt man das kaum. Bei vielen kleinen Dateien, wie bei dir, sieht das anders aus. Da summieren die sich auf.