TS-883XU mit 8 +16 Disks sehr langsam

    Hallo,


    wir verwenden unterschiedliche QNAP Geräte an Außenstandorten als Ziel für Backups. Zugriff erfolgt per SMB. Grundsätzlich haben wir wegen SMB immer mit der der Performance zu kämpfen, aber bei einem speziellen Geräte ist sie so unterirdisch, dass es eigentlich nicht sein kann.


    - TS-883XU-RP mit 8 x 8 TB im RAID 6, dazu REXP-1610U-RP mit 16 x 8 TB im RAID 6 (1 Disk als Spare)

    - 1 Storage Pool mit ~140TB über beide Geräte

    - 85 TB zugewiesen als thick volume, ~60 TB belegt

    - keine Snaps

    - kein Recycle Bin

    - keine Verschlüsselung und keine SMB encryption

    - 2 x 1 GbE

    - ext4 delay allocation aktiv


    Der Schreibdurchsatz liegt aktuell bei ~20 MB/s bei einer Latenz von 90 ms. Selbst Read Operationen sind nicht schneller zu diesen Zeiten. Das war schon mal etwas besser, bricht aber immer nach kurzer Zeit auf diesen Wert ein, oft auch unter 20 MB/s. Mir ist bewusst, dass RAID 6 ein Kompromiss ist, aber RAID 6 Volumes mit solchen Werten habe ich selten gesehen. Der eingebaute Performance Test zeigt 180-240 MB/s read für die Disks.


    Was m it aufgefallen ist, dass das zweite RAID 6 Volume in der Erweiterung praktische keinen IO anzeigt im Monitoring. Der belegte Platz ist aber schon mehr als im Basisgehäuse verfügbar ist, also müsste eigentlich auch auf der Erweiterung mit immerhin 16 Disks geschrieben werden.


    Ich bin ratlos, warum die Performance so schlecht ist. Hat jemand noch Tipps was ich prüfen oder ändern könnte?



    pasted-from-clipboard.png

    Moin,


    wie sind denn die beiden LAN Interfaces konfiguriert? Gibt es hier einen Trunk?

    Sind Probleme im LAN auszuschließen bzw. ist ein ordentlicher Durchsatz hier geprüft und sichergestellt?

    Zitat von Imnothere

    an Außenstandorten

    Da kommt dann wohl auch noch das WAN und ein VPN ins Spiel? Wie genau ist das Konstrukt denn aufgebaut?

    Wie ist die Latenz von der Quelle zum NAS?

    Wenn das über WAN/MAN geht und du hier weit über der LAN 1ms liegst, bricht SMB einfach per Design massiv ein, denn es ist nicht für WAN Strecken optimiert worden.


    Da bist du dann in Bereichen von du mit der Windowsize, MSS, MTU usw. zu kämpfen hast.

    Das Backup erfolgt lokal, es ist also weder WAN noch VPN beteiligt, die Latenz zwischen Backup Server und NAS liegt bei <1ms. Die Interfaces sind aktuell noch nicht in einem bond, das muss noch angepasst werden. Aber selbst mit nur 1GbE Interface müsste ich doch deutlich über 20 MB/s kommen. Nach dem letzten Neustart waren es auch kurzfristig ~115 MB/s was für 1x 1GbE passen würde. Die ~100ms Latenzen die ich in der Performance Anzeige für das RAID sehe, kommen ja vom Storage, da spielt ja das LAN keine Rolle.

    Ok, da sollte in der Tat GBit mit 112MB/s gehen.


    Läuft noch was im Hintergrund, Raid Bereinigung oder was anderes was stark belastet?


    Thick ohne Snaps, sollte auch rennen.


    Ich laste hier mein Raid 5 mit den 4 Exos mit GBit nicht im Ansatz aus.

    Nein, es läuft nichts im Hintergrund.


    Das 12TB backup ist nun nach 9 Tagen fertig. Ich kann es nicht nachvollziehen, ich habe iperf installiert und bekomme vollen Durchsatz (es sind doch 10 GbE, nicht nur 1 GbE). Ich kann vom Backup Server das Share verbinden und 50GB Dateien mit 180 MB/s darauf speichern. Nur das Backup das darauf schreibt ist lahm, als Engpass wird auch das Ziel angegeben. Ich habe schon überlegt ob es an der smb session liegen könnte. Aber ich sehe einfach nichts Auffälliges. Auch per ssh verbunden auf der shell springt nichts ins Auge.

    Einmal editiert, zuletzt von Imnothere ()

    Habe das Problem gefunden, es liegt an "strict allocation = yes" in der smb.conf. Leider bleibt eine Änderung dort nicht über Reboots erhalten, falls jemand weiß wie man das dauerhaft dort ändern kann, wäre das sehr hilfreich.

    Habe ich jetzt ausprobiert, ist leider nicht so richtig elegant. Aber wenn es dauerhaft so funktioniert ist das ok. Die Zeit für ein Veeam synthetic full Backup an einem Standort, ist jetzt von 100 auf 5 Stunden gesunken.

    Ja, und SMB wird auch verwendet. Aber inzwischen ist ja klar, dass es am "strict allocate = yes" liegt.