TS-433 steigert die Leistung

Hallo,

ich versuche, eine hohe sequenzielle Datendurchsatzrate auf meinem NAS (TS-433) für Videobearbeitung / Spaß zu erreichen. Ich mache alles mit der Windows-Dateikopie. Die Feature-Seite sagt, dass 280 MB/s Lesen oder 202 MB/s Schreiben (mit 4 SSDs im RAID 5) möglich sind.

Das ist eine Art Brain Dump und Feedback ist willkommen!
Falls möglich, können Leute bitte teilen, welche Performance sie erreichen? Und wie die Festplatten konfiguriert sind?

Ich habe das NAS/die Festplatten gekauft, bevor ich mich wirklich damit beschäftigt habe. Ich möchte nichts wegwerfen oder verkaufen, vielleicht etwas hinzufügen, um mehr Leistung zu bekommen oder Einstellungen zu optimieren oder zumindest zu verstehen. Das ist mein Ziel.

Mein Setup

TS-433 Qnap v5.2.3.3006 (8. Jan 2025)
2x Seagate 4TB IronWolf im RAID 1 (Spiegelung).
2,5 Gbit Netzwerk für Client und NAS.
Client ist High-End mit NVMe-Speicher.

Als ich das NAS bekommen habe, fühlte es sich die ersten Tage beim Schreiben etwas schneller an… Aber jetzt sind etwa 2TB Daten darauf und es fühlt sich etwas langsamer an (was Sinn ergibt).

Aktuelle Messungen

Dateien vom NAS kopieren: durchschnittlich 155 MB/s mit Spitzen von 175 MB/s.
Dateien auf das NAS kopieren: durchschnittlich 80 MB/s, keine Spitzen (startet für 1 Sekunde hoch).

Ich versuche zu verstehen, warum wir diese Geschwindigkeit erreichen und was der limitierende Faktor ist.

Festplattenleistung
Festplattendurchsatz aus der Qnap-Software:
afbeelding

Über CLI mit einigen alten Basic-Kommandos:

$ hdparm -t /dev/sda -t /dev/sdb -t /dev/md1
/dev/sda:
Timing buffered disk reads: 608 MB in 3.01 seconds = 202.32 MB/sec
/dev/sdb:
Timing buffered disk reads: 592 MB in 3.01 seconds = 196.79 MB/sec
/dev/md1:
Timing buffered disk reads: 802 MB in 3.02 seconds = 265.61 MB/sec

$ echo 3 > /proc/sys/vm/drop_caches && dd if=/dev/sda of=/dev/null bs=1M count=4000
4000+0 records in
4000+0 records out
4194304000 bytes (3.9GB) kopiert, 20.796743 Sekunden, 192.3MB/s

$ echo 3 > /proc/sys/vm/drop_caches && dd if=/dev/sdb of=/dev/null bs=1M count=4000
4000+0 records in
4000+0 records out
4194304000 bytes (3.9GB) kopiert, 21.137790 Sekunden, 189.2MB/s

$ echo 3 > /proc/sys/vm/drop_caches && dd if=/dev/md1 of=/dev/null bs=1M count=4000
4000+0 records in
4000+0 records out
4194304000 bytes (3.9GB) kopiert, 18.758039 Sekunden, 213.2MB/s

Die Festplatten haben 5400 RPM, daher hätte ich niedrigere Werte erwartet.
Aber diese Seite UserBenchmark: Seagate IronWolf 4TB (2016) ST4000VN008
Die Festplatten sind also gut.

Aber das RAID-Gerät (md1) ist langsamer als erwartet. Warum nicht 350 MB/s…

Beim Ausführen von „dd“ habe ich die Festplatten mit iostats überprüft:

                               extended device statistics
 device mgr/s mgw/s    r/s    w/s    kr/s    kw/s   size queue   wait svc_t  %b
 sda        1     1  224.9    4.0 113348.4     7.0  495.2   5.6   23.3   4.2  97
 sdb        1     1  220.9    4.0 111802.8     7.0  497.1   5.1   21.8   4.1  92
 md1        0     0  445.8    3.0 224636.0     6.0  500.5  10.1   22.6   2.2 100
                              extended device statistics
 device mgr/s mgw/s    r/s    w/s    kr/s    kw/s   size queue   wait svc_t  %b
 sda        0     0  241.4    0.5 121807.5     0.0  503.6   4.2   17.6   3.7  90
 sdb        0     0  240.4    0.5 121807.5     0.0  505.6   4.5   18.6   3.8  92
 md1        0     0  477.3    0.0 241061.3     0.0  505.0   8.8   18.5   2.1 100
                              extended device statistics
 device mgr/s mgw/s    r/s    w/s    kr/s    kw/s   size queue   wait svc_t  %b
 sda        0   529  224.5    9.0 113152.0  2129.8  493.7   5.2   21.4   3.9  91
 sdb        1   529  222.5    9.5 111362.0  2139.8  489.2   5.6   23.1   4.2  97
 md1        0     0  449.0    0.0 225280.0     0.0  501.7   9.8   21.8   2.2 100

Ich sehe, dass das Mirror beide Festplatten gleichmäßig nutzt.

Netzwerkdurchsatz
Ich habe iperf installiert. Siehe https://www.qnap.com/en/how-to/faq/article/how-do-i-install-iperf3-in-qts-and-quts-hero

C:\iperf>iperf3.exe -c qnap
Connecting to host qnap, port 5201
[  5] local 192.168.178.174 port 59051 connected to 192.168.178.190 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.01   sec   282 MBytes  2.34 Gbits/sec
[  5]   1.01-2.01   sec   282 MBytes  2.37 Gbits/sec
[  5]   2.01-3.01   sec   284 MBytes  2.37 Gbits/sec
[  5]   3.01-4.01   sec   282 MBytes  2.37 Gbits/sec
[  5]   4.01-5.01   sec   282 MBytes  2.36 Gbits/sec
[  5]   5.01-6.01   sec   282 MBytes  2.37 Gbits/sec
[  5]   6.01-7.01   sec   279 MBytes  2.34 Gbits/sec
[  5]   7.01-8.01   sec   283 MBytes  2.37 Gbits/sec
[  5]   8.01-9.01   sec   283 MBytes  2.36 Gbits/sec
[  5]   9.01-10.01  sec   279 MBytes  2.35 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.01  sec  2.75 GBytes  2.36 Gbits/sec                  sender
[  5]   0.00-10.04  sec  2.75 GBytes  2.36 Gbits/sec                  receiver
iperf Done.

Das sieht gut aus! Das Netzwerk scheint in Ordnung zu sein. Das ist NAS sendet an Client.

NAS-Konfiguration

Zwei Festplatten im RAID1. Kein Bitmap auf dem Mirror.
Festplatten-Setup ist ein logisches Volume vom Typ „Thick“ und keine Snapshots.

Wo verlieren wir Geschwindigkeit?

Nun, die Netzwerkleistung scheint in Ordnung zu sein. Der Festplattendurchsatz ist bei der einzelnen Festplatte gut, aber kombiniert steigt er nicht wie erwartet/erhofft. Unklar, warum. Vielleicht ist die ARM-CPU nicht bereit, wenn die Daten ankommen? Vielleicht ist die CPU damit beschäftigt, die NIC zu versorgen und die Festplatte zu lesen? Interrupts etc.

Welche Einstellung könnte Verbesserungen bringen?

  • SMB Multichannel
  • Jumbo MTU
  • SMB v3
  • SMB Async

Ich denke, Jumbo Frames machen am meisten Sinn… Werde das testen.

Viele Grüße,
Harry

Ich habe vergessen zu erwähnen, dass ich den NIC-Treiber aktualisieren musste, um eine stabile Leistung zu erzielen.
Schau im alten Forum nach: ts-433 acting strange - Page 2 - QNAP NAS Community Forum

Ich habe darüber nachgedacht, NVME oder SSD als Schreibcache hinzuzufügen.
(Das Lesen wird sich dadurch beim Video-Editing nicht verbessern…)

NAS erweitern

Das NAS verfügt über einen USB-5-Gbit-Port.
Auf meinem Windows-Client erreiche ich 800 MB/s mit meinem USB-NVME (10-Gbit-USB).
Ich habe das USB-NVME am NAS angeschlossen.
Beim Testen des NAS, das das NVME teilt, erreiche ich 150 MB/s.
(Mit einem 5-Gbit-USB-Anschluss am Client bekomme ich mit diesem NVME etwa 400 MB/s.)

$ hdparm -t /dev/sdc
/dev/sdc:
Timing buffered disk reads: 880 MB in 3.00 seconds = 293.06 MB/sec

Ich gehe davon aus, dass die Verarbeitung von Disk/USB/NIC auf dieser ARM-CPU nicht mehr als 150 MB/s zulässt.

Was ist mit den zwei freien Einschüben im NAS?

SSD-Cache

Für dieses NAS nicht möglich. Siehe:

3. Aufgrund von Hardware-Einschränkungen unterstützen TS-216G und TS-x33 NAS keinen SSD-Cache.

QTier
Das ist möglich, birgt aber meiner Meinung nach mehr Risiken. Mit Qtier wird es Teil des Speichers. Dann müsste ich ein Spiegel-Set aus SSD/NVME hinzufügen.
Diese Speicherart ist pro TB teurer, daher erscheint mir das nicht als der richtige Weg. Natürlich ist diese Speicherart immer schnell.

Vielleicht einfach mehr Festplatten hinzufügen, das würde auch die Leseleistung verbessern…

Meine zwei Festplatten im Spiegel „sollten“ eine doppelte Leseleistung und etwas weniger Schreibleistung bringen.

Ein RAID 5 mit 3 Festplatten sollte eine dreifache Leseleistung bringen, aber die Schreibleistung noch weiter senken. (Ein einzelner Schreibvorgang wäre 1 Schreibvorgang + 1 Lesevorgang gefolgt von 1 Parity-Schreibvorgang oder ein dreifacher Schreibvorgang „Full Stripe“)
Also bringt RAID 5 mit 3 oder 4 Festplatten keine Verbesserung der Schreibleistung, also keine Option.

Nehmen wir an, dass die gleichen Festplattentypen jeweils nur 80 MB/s liefern:

Festplatten Raid SMB Lesen / Schreiben
2 1 (Spiegel) 155 / 80 (aktuell)
2 0 155 / 155 (geschätzt)
3 0 235 / 200 (geschätzt)
3 5 235 / 60 (geschätzt)
4 5 235 / 80 (geschätzt)
4 6 235 / 60 (geschätzt)
4 0 280 / 200 (geschätzt)
4 10 280 / 160 (geschätzt)

RAID 0 ist für mich keine Option. RAID 5/6 wird die Schreibleistung nicht verbessern.
Also bleibt für mich nur der Weg, 2 Festplatten hinzuzufügen und ein RAID-10-Volume zu erstellen.

Vorausgesetzt, die CPU kann die Daten von den Festplatten verarbeiten…

Aber zuerst meine Testpläne:

  • Jumbo-Frame-Test
  • Einzelne SSD-Durchsatzmessung in einem separaten Volume auf dem NAS

Viele Grüße,
Harry

Das NAS ist einfach zu langsam… Cache braucht man gar nicht versuchen (funktioniert sowieso nicht)

Wenn du mehr Geschwindigkeit brauchst, wechsle zu einem x86/x64 NAS.

Ich verstehe, dass dies kein besonders schneller NAS ist. Ich versuche, die beworbene Geschwindigkeit zu erreichen.
TS-433 | Produktleistung | QNAP

Die Tests wurden mit RAID5 und SSDs durchgeführt.

Zuletzt habe ich ein 431XeU installiert und die Geschwindigkeiten lagen unter 200MB/s beim Lesen und noch darunter beim Schreiben.

So ist das eben bei diesen ARM-NAS, sie sind in Ordnung für 1GbE oder etwas darüber. Verlassen Sie sich nicht darauf, wenn es um solides 2.5/5/ oder 10 GbE geht.

Ich habe Jumbo Frames mit einer Größe von 9000 eingerichtet.

C:\Users\Beheerder>ping -f -l 8972 192.168.178.200

Ping an 192.168.178.200 mit 8972 Bytes Daten:
Antwort von 192.168.178.200: Bytes=8972 Zeit<1ms TTL=64
Antwort von 192.168.178.200: Bytes=8972 Zeit<1ms TTL=64
Antwort von 192.168.178.200: Bytes=8972 Zeit<1ms TTL=64
Antwort von 192.168.178.200: Bytes=8972 Zeit<1ms TTL=64

Ping-Statistik für 192.168.178.200:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ungefähre Rundreisezeiten in Millisekunden:
    Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

Kopieren von NVME über USB mit Jumbo stieg von 130 MB/s auf 162 MB/s.
Kopieren auf NVME erreicht maximal 213 MB/s und bleibt bei 200 MB/s.

Seltsam, dass das Lesen langsamer ist als das Schreiben…
Aber wir haben das Maximum erreicht, wie QNAP beim Schreiben angibt. Großartig!

Während des Tests auf dem Spiegel sehe ich hohe Ausschläge, aber ich höre, wie die Festplatte viel sucht, und das kostet viel Durchsatz.

Also habe ich ein zusätzliches Volume als Thick auf dem Pool erstellt und erneut getestet.

Beim Schreiben von Dateien auf das NAS bekomme ich Ausschläge von 180 MB/s und einen Durchschnitt von 160 MB/s.
Das ist die maximale Geschwindigkeit, die das Festplatten-Array leisten kann!

Beim Lesen von Dateien vom NAS bekomme ich einen Durchschnitt von 220 MB/s mit Ausschlägen bis 250 MB/s.

Ich kann folgendes Fazit ziehen:

  • Der neue RTL8125 macht einen Unterschied!
  • Ein leeres Volume scheint zu verhindern, dass die Festplatten viel suchen.
  • Jumbo Frames helfen wirklich.

Die Leistung, die ich jetzt habe, ist ausreichend.
Beim Schreiben gibt es wenig zu verbessern. (Ich habe 80 % des Maximums)
Beim Lesen gibt es ebenfalls wenig zu verbessern. (Ich habe 78 % des Maximums)

Die SSD werde ich später testen.

Lassen Sie uns die Tabelle mit meinen Schätzungen aktualisieren.
Die Tabelle bezieht sich auf 5400 Ironwolf-Festplatten und Jumbo Frames auf 9000.
Auf frisch leeren Volumes.

Festplatten RAID SMB Lesen / Schreiben
2 1 (Spiegelung) 220 / 160 (aktuell)
2 0 240 / 200 (geschätzt)
3 0 280 / 200 (geschätzt)
3 5 280 / 120 (geschätzt)
4 5 280 / 160 (geschätzt)
4 6 280 / 105 (geschätzt)
4 0 280 / 200 (geschätzt)
4 10 280 / 200 (geschätzt)
1 Einzelne SSD-Festplatte 290 / 290 (aktuell!)

Das hat mich über das leere Volume nachdenken lassen.
Meine Festplatten haben nur 5400 U/min, die zufällige I/O-Leistung ist miserabel und sollte vermieden werden.

Das Problem eines gefüllten Volumes wäre also die Fragmentierung.
Ich habe Entware verwendet, um filefrag zu installieren. Damit kann ich die Fragmentierung einer Datei überprüfen.

Der schnelle Kopiervorgang einer 10-GByte-Datei auf die leere Festplatte:

$ /opt/sbin/filefrag -v TEST_FILE
TEST_FILE: 11 Extents gefunden

Die schlechte Performance beim Kopieren auf die normale Festplatte 2,4 TB / 300 GB frei.

$ /opt/sbin/filefrag -v TEST_FILE
TEST_FILE: 124 Extents gefunden

124 vs 11 Extents. Das bestätigt das Fragmentierungsproblem.

Ich habe das Tool „e2freefrag“ gefunden, das einige Einblicke gibt.

Das neue Volume

$ e2freefrag /dev/mapper/cachedev2
Device: /dev/mapper/cachedev2
Blocksize: 4096 bytes
Total blocks: 78643200
Free blocks: 77744836 (98.9%)

Min. free extent: 4 KB
Max. free extent: 2080640 KB
Avg. free extent: 1851064 KB
Num. free extent: 168

HISTOGRAMM DER FREIEN EXTENT-GRÖSSEN:
Extent Size Range :  Freie Extents   Freie Blöcke  Prozent
    4K...    8K-  :             1             1    0.00%
   64M...  128M-  :             6        170768    0.22%
  128M...  256M-  :             5        322362    0.41%
  256M...  512M-  :             2        191417    0.25%
  512M... 1024M-  :             6       1236804    1.59%
    1G...    2G-  :           148      75823484   97.53%

Mein Produktionsvolume

$ e2freefrag /dev/mapper/cachedev1
Device: /dev/mapper/cachedev1
Blocksize: 4096 bytes
Total blocks: 655360000
Free blocks: 74780720 (11.4%)

Min. free extent: 4 KB
Max. free extent: 2080640 KB
Avg. free extent: 16856 KB
Num. free extent: 17743

HISTOGRAMM DER FREIEN EXTENT-GRÖSSEN:
Extent Size Range :  Freie Extents   Freie Blöcke  Prozent
    4K...    8K-  :           751           751    0.00%
    8K...   16K-  :           689          1639    0.00%
   16K...   32K-  :           892          4733    0.01%
   32K...   64K-  :          1221         13626    0.02%
   64K...  128K-  :           683         14679    0.02%
  128K...  256K-  :           550         25336    0.03%
  256K...  512K-  :           716         66956    0.09%
  512K... 1024K-  :          1414        260150    0.35%
    1M...    2M-  :          1720        648493    0.87%
    2M...    4M-  :          2645       1989195    2.66%
    4M...    8M-  :          3854       5748362    7.69%
    8M...   16M-  :          1349       3778962    5.05%
   16M...   32M-  :           466       2614941    3.50%
   32M...   64M-  :           270       2748786    3.68%
   64M...  128M-  :           396      11086409   14.83%
  128M...  256M-  :            17        834022    1.12%
  256M...  512M-  :             7        666937    0.89%
  512M... 1024M-  :            20       3767726    5.04%
    1G...    2G-  :            83      40509017   54.17%

Ich bin mir nicht sicher, wo ich hinschauen soll…

Ich habe viel über ext4 und Fragmentierung gelesen.
Es scheint, dass man immer mindestens 20 % freien Speicherplatz haben sollte.
(das habe ich nicht gemacht…)

Ich habe etwas zur Defragmentierung auf dem Festplatten-Array recherchiert.
Ich kann e4defrag auf QNAP nicht finden, aber ich habe „shake“ gefunden.

$ filefrag ccie.rtf
ccie.rtf: 2 Extents gefunden
$ shake --old 0 --bigsize 0 ccie.rtf
$ filefrag ccie.rtf
ccie.rtf: 1 Extent gefunden

Jetzt habe ich also eine Waffe :slight_smile:

Können wir unnötige I/O auf den Festplatten entfernen?

Ich habe einiges ausprobiert

Ich habe das Dateisystem-Journal deaktiviert, aber QNAP mochte das überhaupt nicht…
Mit Optionen auf ext4 wie largefile4 und bigalloc herumgespielt.
Nun, das QNAP-GUI mag das nicht…
Ich konnte das Volume mit dem QNAP-CLI neu formatieren, damit das GUI wieder zufrieden ist.
qcli_volume -f volumeID=2 action=start inode=65536

Über die CLI kann man das machen, aber das hilft beim Video-Editing nicht…

$ mount /dev/mapper/cachedev1 -o remount,noatime

Der einzige Fortschritt ist vielleicht die 65k-Option beim Formatieren mit QNAP.
Aber ich bin mir nicht sicher…

Ich denke, ich sollte zwei „thick“ Volumes machen:
Ein Volume speziell für Video (große Dateien für sequentiell)
Ein Volume für alles andere.

Ich muss die SSD noch testen, ich bin ziemlich sicher, dass ich hohe Werte bekommen werde.

Viele Grüße!

Entware-Tools:

shake - 1.0-20170702-1 - Shake ist ein Defragmentierer, der im Userspace läuft.
filefrag - 1.47.0-2 - Ext2-Dateisystem-Dateifragmentierungsbericht-Utility
e2freefrag - 1.47.0-2 - Ext2-Dateisystem-Utility für Informationen zur Fragmentierung des freien Speicherplatzes

SSD installiert und 290 MB/s / 290 MB/s Durchsatz erhalten.
Das ist mehr als ich für den Schreibvorgang erwartet habe.

Tests in der QNAP-Software zeigen eine Festplattendurchsatzrate von 530 MB/s.

Ich vermute, dass ich mit RAID 10 auf HDD auch diese Art von Leistung erreichen kann, wenn ich das Fragmentierungsproblem in den Griff bekomme.

Fürs Erste bleibe ich bei den 2 Festplatten im Spiegelmodus.
Ich werde ein Volume für große Dateien und ein weiteres für den Rest anlegen, beide mit genügend freiem Speicherplatz. Das sollte die Fragmentierung gering halten.

Über weitere Hinweise freue ich mich! Bitte teilt mir mit, welche Leistung ihr mit welchen Festplatten erzielt.

Ich habe das Problem, dass nach dem Laden des gefixten Netzwerktreibers die GUI die Netzwerkkarte nicht mehr anzeigt. Kennt jemand eine Lösung? Ich warte darauf, dass QNAP ein Update mit diesem Treiber herausbringt.

Viele Grüße!

Ich habe einiges überdacht und erneut getestet.
Und ich habe NICHT die gleiche Leistung während der Tests erhalten.

Netzwerk erneut getestet

C:\iperf>iperf3.exe -c 192.168.178.200
Connecting to host 192.168.178.200, port 5201
[  5] local 192.168.178.174 port 50682 connected to 192.168.178.200 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.01   sec   270 MBytes  2.23 Gbits/sec
[  5]   1.01-2.01   sec   290 MBytes  2.43 Gbits/sec
[  5]   2.01-3.01   sec   295 MBytes  2.48 Gbits/sec
[  5]   3.01-4.01   sec   295 MBytes  2.48 Gbits/sec
[  5]   4.01-5.01   sec   295 MBytes  2.48 Gbits/sec
[  5]   5.01-6.01   sec   284 MBytes  2.39 Gbits/sec
[  5]   6.01-7.00   sec   266 MBytes  2.24 Gbits/sec
[  5]   7.00-8.00   sec   296 MBytes  2.48 Gbits/sec
[  5]   8.00-9.00   sec   296 MBytes  2.48 Gbits/sec
[  5]   9.00-10.00  sec   295 MBytes  2.48 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  2.81 GBytes  2.42 Gbits/sec                  sender
[  5]   0.00-10.03  sec  2.81 GBytes  2.41 Gbits/sec                  receiver

iperf Done.

Das Volume gelöscht und immer wieder neu erstellt, mit unterschiedlichen Größen, und plötzlich waren die Ergebnisse wieder gut.
Das ergab für mich keinen Sinn. Das würde darauf hindeuten, dass ein bestimmter Sweetspot im Festplatten-Array wichtig ist.

Ich habe einfaches DD mit einem Offset verwendet, um die Leistung zu testen. Und es stellte sich heraus, dass die Geschwindigkeit am Ende wirklich deutlich geringer ist!
Natürlich ist das bei einem Laufwerk zu erwarten, dass der äußere Bereich schneller ist als der innere, aber ich hätte nicht erwartet, dass der Unterschied den Faktor 2 ausmacht.

Ich habe jede Festplatte und dann das Mirror getestet:

[admin@QNAP /]# for i in `seq 0 500 3500`; do  echo  "offset $i Gigabytes";echo 3 > /proc/sys/vm/drop_caches && dd if=/dev/sda of=/dev/null bs=1M count=500 skip=${i}K; done
offset 0 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 2.454363 seconds, 203.7MB/s
offset 500 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 2.506304 seconds, 199.5MB/s
offset 1000 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 2.983244 seconds, 167.6MB/s
offset 1500 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 2.825006 seconds, 177.0MB/s
offset 2000 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 3.615630 seconds, 138.3MB/s
offset 2500 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 3.578937 seconds, 139.7MB/s
offset 3000 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 4.422567 seconds, 113.1MB/s
offset 3500 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 4.839563 seconds, 103.3MB/s
[admin@QNAP /]# for i in `seq 0 500 3500`; do  echo  "offset $i Gigabytes";echo 3 > /proc/sys/vm/drop_caches && dd if=/dev/sdb of=/dev/null bs=1M count=500 skip=${i}K; done
offset 0 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 2.588500 seconds, 193.2MB/s
offset 500 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 2.617839 seconds, 191.0MB/s
offset 1000 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 2.797189 seconds, 178.8MB/s
offset 1500 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 2.917865 seconds, 171.4MB/s
offset 2000 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 2.919876 seconds, 171.2MB/s
offset 2500 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 3.717384 seconds, 134.5MB/s
offset 3000 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 4.240667 seconds, 117.9MB/s
offset 3500 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 5.708912 seconds, 87.6MB/s
[admin@QNAP /]# for i in `seq 0 500 3500`; do  echo  "offset $i Gigabytes";echo 3 > /proc/sys/vm/drop_caches && dd if=/dev/md1 of=/dev/null bs=1M count=500 skip=${i}K; done
offset 0 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 2.179269 seconds, 229.4MB/s
offset 500 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 2.088836 seconds, 239.4MB/s
offset 1000 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 2.301137 seconds, 217.3MB/s
offset 1500 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 3.947950 seconds, 126.6MB/s
offset 2000 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 3.064201 seconds, 163.2MB/s
offset 2500 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 2.718814 seconds, 183.9MB/s
offset 3000 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 3.425079 seconds, 146.0MB/s
offset 3500 Gigabytes
500+0 records in
500+0 records out
524288000 bytes (500.0MB) copied, 3.747751 seconds, 133.4MB/s

Also habe ich gelernt, dass das SCHNELLE Volume das erste sein muss.
Das letzte 1 TB ist selbst mit dem Mirror zu langsam, um hohen Durchsatz zu liefern.

Ein Volume mit viel freiem Speicherplatz hat weniger Fragmentierung, aber wir müssen den letzten Teil der Festplatten für Geschwindigkeit vermeiden.

Ich habe viel gelernt!

Das nennt man anscheinend „Short Stroke“.

Bei dieser Festplatte scheint es ein „guter“ Kompromiss zu sein, bei etwa 2300 GB zu teilen. Das sind 70 % der Festplatte. Wahrscheinlich ist das bei jeder Festplatte ungefähr gleich.

Erstes Volume: GROßE Dateien
Zweites Volume: „Platz für Snapshots“ 100 GB?
Drittes Volume: der Rest für kleine Dateien.

Leider ist es meines Wissens nach bei QNAP nicht möglich, einen dedizierten Bereich für Snapshots zu erstellen. Die Snapshots landen daher wahrscheinlich auf dem langsamsten Teil.

Ich werde das NAS löschen und neu aufbauen.
Mit 3 Volumes und später werde ich das mittlere Volume löschen, damit es zum Snapshot-Bereich werden kann.

Es ist ein schönes Puzzle, das mir Spaß macht. Natürlich, wenn man seine Zeit ernst nimmt, sollte man mehr schnelle Festplatten und ein schnelles NAS kaufen – und wenn man schon dabei ist, gleich auf 10 Gbit setzen!

Ich habe hier auch Leistungsprobleme mit meinem TS-435XeU.

Ich nutze 10GE, sehe aber nur ein paar Gbit/s. Ich habe mich für SMB v3, Jumbo Frames, Async usw. entschieden und die Einstellungen auf dem Mac, den ich als Client verwende, angepasst. Mac zu Mac erreiche ich problemlos 10 Gbit/s, das Problem liegt also eindeutig am NAS.

QNAP behauptet, dass ich mit diesem Modell 10GE erreichen sollte:

https://www.qnap.com/en-uk/performance/model/ts-435xeu

Hat jemand Ideen (außer „es ist eine ARM-CPU, also schafft sie nur 1 Gigabit“)?

Hast du also exakt das gleiche Setup wie sie?

Client-Computer:

  • Betriebssystem: Microsoft Windows Server 2019
  • Spezifikation: Intel® Core™ i7-7700 (4C/8T), 32GB RAM, QNAP 10GbE/25GbE/100GbE Netzwerkerweiterungskarte

NAS-Konfiguration:

  • Betriebssystem: QTS 4.5.x & 5.0.0
  • RAID-Volume: RAID 50 (8 Einschübe und mehr), RAID 5 (4 bis 6 Einschübe), RAID 1 (2 Einschübe), Single (1 Einschub)
  • SSD / HDD: Voll bestückt, Samsung 860 EVO 1TB SATA SSD / Seagate ST1000NM0033 1TB HDD / Samsung PM9A1 960GB M.2 NVMe PCIe Gen4 / Samsung PM9A3 (MZQL2960HCJR-00A07) 960GB U.2 NVMe PCIe Gen4
  • 2.5GbE & GbE: integrierte Ethernet-Ports
  • Netzwerkkarte: 10GbE: QNAP Dual-Port 10 Gigabit Netzwerkerweiterungskarte (LAN-10G2T-U oder LAN-10G2SF-MLX)
  • Netzwerkkarte: 25GbE: QNAP Dual-Port 25 Gigabit Netzwerkerweiterungskarte (QXG-25G2SF-CX6)
  • Netzwerkkarte: 100GbE: QNAP Dual-Port 100 Gigabit Netzwerkerweiterungskarte (QXG-100G2SF-E810 oder QXG-100G2SF-CX6)

QNAP verwendete dies als ihr Demosystem

Diese Zahlen sind auf keinen Fall erreichbar, ich konnte mit einem 431XeU (1x SFP+) kaum 250 MB/s erreichen.

Natürlich habe ich nicht exakt das gleiche Setup. Besonders da das auf der Website angegebene Setup nicht das ist, das sie getestet haben (eigentlich unmöglich, denke ich, da das TS-435XeU integriertes 10GE hat, aber meines Wissens keine Unterstützung für zusätzliche NICs bietet).

Das korrekte Setup (glaube ich) ist hier zu finden:

https://www.qnap.com/en-uk/product/ts-435xeu

Jedenfalls verwende ich eine neuere Software-Version als die, die sie getestet haben (wie zu erwarten).

Der Client-Computer ist offensichtlich kein Problem (da ich mit einem zweiten Mac als SMB-Server 10 Gbps erreichen kann).

Der entscheidende Unterschied ist wahrscheinlich, dass ich kein 4 x SSD RAID-Setup habe (ich verwende gute alte HDDs, allerdings 7200 RPM). Also ja – könnte an den Festplatten liegen, obwohl ich gehofft hatte, dass die Leselast auf die Platten verteilt wird…

Nach dem, was ich gelesen habe, werden die M.2 SSDs im TS-435XeU ziemlich heiß, daher zögere ich, diese einzubauen. Und ebenso möchte ich eigentlich nicht so viel Geld ausgeben, um die HDDs durch SSDs zu ersetzen…

Um Geschwindigkeiten von 10 Gb oder 2x 10 Gb Ethernet zu erreichen, benötigt man wirklich keine rotierenden Festplatten.

Die getestete SSD hat 550 MB/s pro Laufwerk, sodass mit 4 Laufwerken die angegebenen 2235 MB/s erreicht werden können. Es handelt sich um SSDs, daher spielt es keine große Rolle, ob die Zugriffe zufällig oder sequenziell sind.

Du hast dein Setup nicht geteilt. RAID 10? 4 Laufwerke? Leeres Volume? Thick? Snapshots? Leseleistung? Schreibleistung?

Eine schnelle HDD schafft nicht mehr als 220 MB/s und im besten Fall bekommst du vielleicht 800 MB/s? Aber wenn du den langsamen Bereich der Festplatten nutzt, bekommst du nur etwa 300 MB/s oder etwas in der Richtung.

Wenn du ein Snapshot oder ein Thin Volume hast, gibt es viele zufällige I/O-Zugriffe und die Geschwindigkeit sinkt stark. Insgesamt etwa 30–60 MB/s.

Dies ist RAID 1 auf einem Thick-Volume.

Ich sehe 1,8 Gbps beim Lesen und 1,4 Gbps beim Schreiben (also jeweils 225 MB/s und 175 MB/s).

Die Festplatten sind Ironwolf Pros, sollten also ziemlich schnell sein (ich glaube, sie geben 220 MB/s anhaltende Lese-/Schreibgeschwindigkeit an).

Ich hatte gehofft, dass ich bei RAID 1 in etwa die doppelte Lesegeschwindigkeit einer einzelnen Festplatte erreichen würde, da verschiedene Cluster von unterschiedlichen Festplatten gelesen werden können – wobei vermutlich etwas zusätzlicher Suchaufwand entsteht, wenn die Festplatte nach jedem Lesevorgang vom Ende von Cluster N zum Anfang von Cluster N+2 springt?

Jedenfalls klingt es so, als wären SSDs die Lösung?

RAID1-Daten werden gleichzeitig von beiden Festplatten gelesen, daher gibt es keine Geschwindigkeitsverbesserung gegenüber einer einzelnen Festplatte.
Bei mehreren Block-Lesevorgängen (mehrere Clients greifen auf verschiedene Dateien zu) können Verbesserungen auftreten.

Ich habe die CPU-Spezifikationen überprüft und der TS-435XeU ist besser als der TS-433.

Dein Setup scheint meinem ziemlich ähnlich zu sein. Ich habe 220/160 mit einem RAID1 aus 2 Ironwolf-Festplatten (nicht Pro) bekommen.

Ich hatte gehofft, dass ich im RAID 1 nahe an die doppelte Lesegeschwindigkeit einer einzelnen Festplatte komme, da verschiedene Cluster von unterschiedlichen Festplatten gelesen werden können – wobei vermutlich etwas Suchzeit dazukommt, wenn die Festplatte vom Ende von Cluster N zum Anfang von Cluster N+2 nach jedem Lesevorgang springt?

In meinem Setup sehe ich eine gewisse Verbesserung der Lesegeschwindigkeit beim Spiegeln. Mit anderen RAID-Leveln wird sich das noch mehr verbessern.

Auf jeden Fall klingt es so, als wären SSDs die Lösung?

Ja, mit SSDs bekommst du die hohen Werte.