TS-433 tingkatkan performa

Hai,

Saya sedang mencoba mendapatkan throughput data sekuensial tinggi di NAS (TS-433) untuk editing video / sekadar bersenang-senang. Saya melakukan semuanya dengan copy file di Windows. Halaman fitur menyebutkan 280 MB/s baca atau 202 MB/s tulis (dengan 4 disk SSD RAID 5).

Ini semacam curahan pikiran dan masukan sangat diterima!
Jika memungkinkan, bisakah orang-orang berbagi performa yang mereka dapatkan? Dan konfigurasi disk-nya?

Saya membeli NAS/disk sebelum benar-benar meneliti semuanya. Saya tidak ingin membuang atau menjual, mungkin menambah sesuatu untuk meningkatkan performa atau mengutak-atik pengaturan atau setidaknya memahami. Itu tujuan saya.

Setup saya

TS-433 Qnap v5.2.3.3006 (8 Jan 2025)
2x Seagate 4TB IronWolf dalam RAID 1 (mirror).
Jaringan 2.5 Gbit di klien dan NAS.
Klien adalah high end dengan penyimpanan NVMe.

Saat pertama kali mendapat NAS, rasanya beberapa hari pertama lebih cepat saat menulis data ke NAS.. Tapi sekarang sudah ada sekitar 2TB data di dalamnya, rasanya agak lebih lambat (yang masuk akal).

Pengukuran saat ini

Copy file dari NAS rata-rata 155 MB/s dengan lonjakan sampai 175 MB/s.
Copy file ke NAS rata-rata 80 MB/s tanpa lonjakan (hanya tinggi di 1 detik awal).

Saya mencoba memahami kenapa kecepatan segini dan apa faktor pembatasnya.

Performa Disk
Throughput disk dari software qnap:
afbeelding

Melalui CLI dengan beberapa perintah dasar lama:

$ 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) copied, 20.796743 seconds, 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) copied, 21.137790 seconds, 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) copied, 18.758039 seconds, 213.2MB/s

Disk-nya 5400 RPM jadi saya ekspektasi nilainya lebih rendah.
Tapi situs ini UserBenchmark: Seagate IronWolf 4TB (2016) ST4000VN008
Jadi disk-nya bagus.

Tapi perangkat RAID (md1) lebih lambat dari ekspektasi. Kenapa tidak 350 MB/s..

Saat menjalankan “dd” saya cek disk dengan iostats:

                               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

Saya lihat mirror menggunakan kedua disk secara seimbang.

Throughput Jaringan
Saya install iperf. Lihat 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.

Itu terlihat bagus! Jaringan sepertinya oke. Ini NAS mengirim ke klien.

Konfigurasi NAS

Dua disk dalam RAID1. Tidak ada bitmap di mirror.
Setup disk satu logical volume tipe thick dan tanpa snapshot.

Jadi di mana kita kehilangan kecepatan?

Ya, performa jaringan kelihatannya baik. Throughput disk bagus di single disk tapi kalau digabung tidak meningkat seperti yang saya harapkan. Tidak jelas kenapa. Mungkin saat data datang CPU ARM-nya belum siap? Mungkin CPU sibuk melayani NIC dan membaca disk? Interrupt dan lain-lain.

Pengaturan mana yang bisa ditingkatkan?

  • SMB multichannel
  • Jumbo MTU
  • SMB v3
  • SMB Async

Saya rasa Jumbo frames paling masuk akal.. Akan saya tes ini.

Salam,
Harry

Saya lupa mengatakan bahwa saya perlu memperbarui driver NIC untuk mendapatkan performa yang stabil.
Cek forum lama ts-433 acting strange - Page 2 - QNAP NAS Community Forum

Saya sedang mempertimbangkan untuk menambahkan NVME atau SSD sebagai cache penulisan.
(membaca tidak akan meningkat untuk pengeditan video dengan ini…)

Perluas NAS

NAS memiliki port USB 5 Gbit.
Di klien Windows saya, saya mendapatkan 800MB/s dari USB NVME saya (USB 10 Gbit).
Saya menghubungkan USB NVME ke NAS.
Saat menguji NAS yang membagikan NVME, saya mendapatkan 150 MB/s.
(Dengan slot USB 5 Gbit di klien, saya mendapatkan sekitar 400 MB/s dengan NVME ini)

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

Saya berasumsi penanganan disk/usb/nic pada CPU ARM ini tidak mampu lebih dari 150 MB/s.

Bagaimana dengan dua bay kosong di NAS?

SSD Cache

Tidak memungkinkan untuk NAS ini. Lihat:

3. Karena keterbatasan hardware, TS-216G dan NAS TS-x33 tidak mendukung cache SSD.

QTier
Nah, ini memungkinkan tapi saya pikir ada beberapa risiko lebih. Dengan Qtier, ini menjadi bagian dari penyimpanan. Maka saya harus menambahkan mirror SSD/NVME.
Jenis penyimpanan ini per TB lebih mahal jadi rasanya bukan pilihan. Tentu saja penyimpanan jenis ini selalu cepat.

Mungkin menambah disk lagi, itu juga akan meningkatkan performa baca…

Dua disk saya dalam mirror “seharusnya” memberikan performa baca dua kali lipat dan performa tulis sedikit lebih rendah.

Raid 5 dengan 3 disk seharusnya memberikan performa baca tiga kali lipat tapi akan menurunkan performa tulis lebih jauh. (Satu penulisan akan menjadi 1 tulis + 1 baca diikuti 1 tulis parity atau satu penulisan triple “full stripe”)
Jadi raid 5 dengan 3 atau 4 disk tidak akan menambah performa tulis jadi bukan opsi.

Mari kita asumsikan jika kita menambahkan tipe disk yang sama hanya memberikan 80 Mb/s untuk setiap disk:

Disk Raid SMB Baca / Tulis
2 1 (mirror) 155 / 80 (saat ini)
2 0 155 / 155 (perkiraan saya)
3 0 235 / 200 (perkiraan saya)
3 5 235 / 60 (perkiraan saya)
4 5 235 / 80 (perkiraan saya)
4 6 235 / 60 (perkiraan saya)
4 0 280 / 200 (perkiraan saya)
4 10 280 / 160 (perkiraan saya)

Raid 0 bukan opsi untuk saya. Raid 5/6 tidak akan membantu performa tulis.
Jadi satu-satunya jalan yang saya lihat adalah menambah 2 disk dan membuat volume raid 10.

Dengan asumsi CPU mampu menangani data dari disk…

Tapi pertama rencana pengujian saya:

  • Pengujian Jumbo
  • Tes throughput SSD tunggal di volume terpisah pada NAS

Salam,
Harry

NAS-nya memang terlalu lambat.. tidak perlu mencoba cache (toh rusak juga)

Jika Anda membutuhkan kecepatan lebih, beralihlah ke NAS x86/x64

Saya mengerti bahwa ini bukan NAS yang sangat cepat. Saya sedang mencoba mendapatkan kecepatan sesuai yang diiklankan.
TS-433 | Kinerja Produk | QNAP

Pengujian dilakukan dengan RAID5 dan SSD

Terakhir saya memasang 431XeU dan kecepatan baca di bawah 200MB/s, bahkan lebih rendah untuk menulis.

Memang seperti itulah NAS ARM ini, mereka cukup untuk 1GbE atau sedikit di atasnya. Jangan berharap banyak untuk koneksi 2.5/5/atau 10 GbE yang stabil.

Saya telah mengatur Jumbo frames dengan ukuran 9000.

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

Pinging 192.168.178.200 dengan 8972 byte data:
Reply from 192.168.178.200: bytes=8972 time<1ms TTL=64
Reply from 192.168.178.200: bytes=8972 time<1ms TTL=64
Reply from 192.168.178.200: bytes=8972 time<1ms TTL=64
Reply from 192.168.178.200: bytes=8972 time<1ms TTL=64

Statistik ping untuk 192.168.178.200:
    Paket: Dikirim = 4, Diterima = 4, Hilang = 0 (0% hilang),
Perkiraan waktu perjalanan pulang-pergi dalam milidetik:
    Minimum = 0ms, Maksimum = 0ms, Rata-rata = 0ms

Menyalin dari NVME di USB dengan Jumbo meningkat dari 130 MB/s menjadi 162 MB/s
Menyalin ke NVME mencapai puncak 213 MB/s dan stabil di sekitar 200 MB/s

Aneh bahwa baca lebih lambat dari tulis..
Tapi kita mendapatkan kecepatan maksimum seperti yang dikatakan QNAP untuk tulis. Hebat!

Saat melakukan tes pada mirror saya melihat lonjakan tinggi tapi saya mendengar disk banyak melakukan seek dan itu sangat mengurangi throughput.

Jadi saya membuat volume tambahan tipe thick di pool dan mengujinya lagi.

Menulis file ke NAS saya mendapat lonjakan 180 MB/s dan rata-rata 160 MB/s
Ini adalah kecepatan maksimum yang bisa dilakukan oleh disk array!

Membaca file dari NAS saya mendapatkan rata-rata sekitar 220 MB/s dengan lonjakan hingga 250 MB/s.

Saya dapat menyimpulkan hal berikut:

  • RTL8125 baru benar-benar membuat perbedaan!
  • Volume kosong tampaknya mencegah disk melakukan seek terlalu banyak.
  • Jumbo frames benar-benar membantu

Performa yang saya dapatkan sekarang sudah cukup baik.
Untuk bagian tulis tidak banyak yang bisa ditingkatkan. (saya sudah dapat 80% dari maksimum)
Untuk bagian baca juga tidak banyak yang bisa ditingkatkan. (saya sudah dapat 78% dari maksimum)

Saya akan menguji SSD nanti.

Mari kita perbarui tabel dengan tebakan saya.
Tabel ini menggunakan disk Ironwolf 5400 dan Jumbo frames pada 9000
Pada volume yang baru dan kosong.

Disk Raid SMB Baca / Tulis
2 1 (mirror) 220 / 160 (saat ini)
2 0 240 / 200 (perkiraan saya)
3 0 280 / 200 (perkiraan saya)
3 5 280 / 120 (perkiraan saya)
4 5 280 / 160 (perkiraan saya)
4 6 280 / 105 (perkiraan saya)
4 0 280 / 200 (perkiraan saya)
4 10 280 / 200 (perkiraan saya)
1 single disk SSD 290 / 290 (saat ini!)

Ini membuat saya berpikir tentang volume kosong.
Disk saya hanya 5400 rpm, performa random I/O sangat buruk dan sebaiknya dihindari.

Jadi masalah pada volume yang sudah terisi adalah fragmentasi.
Saya menggunakan Entware untuk menginstal filefrag. Ini memungkinkan saya memeriksa fragmentasi sebuah file.

Jadi, copy cepat file 10 GByte ke disk kosong:

$ /opt/sbin/filefrag -v TEST_FILE
TEST_FILE: 11 extents ditemukan

Copy dengan performa buruk ke disk normal 2.4 TB / 300 GB Free.

$ /opt/sbin/filefrag -v TEST_FILE
TEST_FILE: 124 extents ditemukan

124 vs 11 extents. Ini mengonfirmasi masalah fragmentasi.

Saya menemukan tool “e2freefrag”. Yang memberikan beberapa wawasan.

Volume baru

$ 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

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
    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%

Volume produksi saya

$ 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

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
    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%

Saya tidak yakin apa yang saya lihat…

Saya sudah banyak membaca tentang ext4 dan fragmentasi.
Sepertinya Anda harus selalu memastikan ada setidaknya 20% ruang kosong.
(itu bukan yang saya lakukan…)

Cari sedikit tentang defragmentasi pada disk array.
Saya tidak bisa menemukan e4defrag di QNAP tapi saya menemukan “shake”.

$ filefrag ccie.rtf
ccie.rtf: 2 extents ditemukan
$ shake --old 0 --bigsize 0 ccie.rtf
$ filefrag ccie.rtf
ccie.rtf: 1 extents ditemukan

Jadi sekarang saya punya senjata :slight_smile:

Bisakah kita mengurangi beberapa I/O yang tidak perlu di disk?

Saya mencoba beberapa hal

Saya menonaktifkan filesystem journal tapi QNAP sama sekali tidak suka ini..
Bermain-main dengan opsi di ext4 seperti largefile4 dan bigalloc.
Tapi GUI QNAP tidak suka ini…
Saya bisa memformat ulang volume dengan qnap cli agar GUI senang lagi.
qcli_volume -f volumeID=2 action=start inode=65536

Dari cli Anda bisa lakukan, tapi ini tidak membantu untuk editing video…

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

Satu-satunya langkah maju mungkin adalah opsi 65k saat memformat dengan QNAP.
Tapi tidak yakin…

Saya pikir saya harus membuat dua volume tebal:
Satu volume khusus untuk video (file besar untuk sekuensial)
Satu volume untuk semua yang lain.

Saya masih perlu menguji SSD, saya cukup yakin akan mendapat nilai tinggi.

Cheers!

Tool Entware:

shake - 1.0-20170702-1 - Shake adalah defragmenter yang berjalan di userspace.
filefrag - 1.47.0-2 - Utilitas laporan fragmentasi file pada Filesystem Ext2
e2freefrag - 1.47.0-2 - Utilitas informasi fragmentasi ruang kosong pada Filesystem Ext2

Sudah memasang SSD dan mendapatkan 290 MB/s / 290 MB/s throughput.
Itu lebih dari yang saya harapkan untuk bagian penulisan.

Pengujian di software QNAP menunjukkan throughput disk sebesar 530 MB/s

Saya rasa dengan RAID 10 pada HDD saya juga akan mendapatkan performa seperti ini jika bisa mengatasi masalah fragmentasi.

Untuk saat ini saya akan tetap menggunakan 2 disk dalam mode mirror.
Akan membuat satu volume untuk file besar dan satu lagi untuk sisanya, keduanya dengan ruang kosong yang cukup. Itu seharusnya menjaga fragmentasi tetap rendah.

Masukan tetap sangat dihargai! Silakan beri tahu saya performa yang Anda dapatkan dengan disk apa.

Saya mengalami masalah ketika saya memuat driver jaringan yang sudah diperbaiki, GUI tidak lagi menampilkan NIC. Ada yang tahu solusinya? Saya sedang menunggu QNAP merilis pembaruan dengan driver ini di dalamnya.

Salam!

Saya melakukan beberapa pemikiran ulang dan pengujian ulang.
Dan saya TIDAK mendapatkan performa yang sama selama pengujian.

Pengujian ulang jaringan

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.

Saya menghapus dan membuat volume lagi dan lagi dengan beberapa ukuran berbeda dan tiba-tiba hasilnya bagus lagi.

Hal itu tidak masuk akal bagi saya. Ini mengindikasikan bahwa ada titik manis tertentu pada array disk yang penting.

Saya menggunakan DD sederhana dengan offset untuk menguji performa. Dan ternyata kecepatan di bagian akhir benar-benar jauh lebih lambat!
Tentu saja ini diharapkan dari sebuah drive di mana bagian luar lebih cepat daripada bagian dalam, tapi saya tidak benar-benar mengira perbedaannya bisa sampai 2 kali lipat.

Saya menguji setiap disk lalu mirror-nya:

[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

Jadi saya belajar bahwa volume CEPAT harus yang pertama.
1 TB terakhir terlalu lambat bahkan dengan mirror untuk memberikan throughput tinggi.

Jadi volume dengan banyak ruang kosong memiliki fragmentasi lebih sedikit tetapi kita perlu menghindari bagian terakhir dari disk untuk kecepatan.

Saya belajar banyak!

Ini disebut short stroke tampaknya.

Untuk disk ini, tampaknya kompromi “baik” adalah membagi di sekitar 2300 GB. Itu sekitar 70% dari disk. Kemungkinan besar untuk setiap disk kurang lebih sama.

Volume pertama FILE BESAR
Volume kedua “ruang untuk snapshot” 100 GB?
Volume ketiga sisanya untuk file kecil.

Sayangnya, sepertinya tidak memungkinkan di QNAP untuk membuat ruang khusus untuk snapshot. Jadi snapshot kemungkinan akan berakhir di bagian paling lambat.

Saya akan menghapus NAS dan membangunnya kembali.
Dengan 3 volume dan nanti saya akan menghapus volume tengah agar bisa menjadi bagian untuk snapshot.

Ini teka-teki yang menarik, saya menikmatinya. Tentu saja, jika Anda benar-benar serius, belilah disk yang lebih cepat dan NAS yang lebih cepat, dan sekalian saja pakai 10 Gbit!

Saya juga mengalami masalah performa di TS-435XeU saya.

Saya menggunakan 10GE tetapi hanya mendapatkan beberapa gbps saja. Saya sudah memilih SMB v3, jumbo frame, async, dll., dan telah memodifikasi pengaturan di Mac yang saya gunakan sebagai klien. Mac ke Mac saya bisa mendapatkan 10gbps dengan baik, jadi masalahnya jelas ada di NAS.

QNAP mengklaim saya seharusnya bisa mendapatkan 10GE dengan ini:

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

Ada yang punya pendapat (selain “itu CPU ARM jadi cuma bisa 1 gig”)?

jadi apakah kamu memiliki setup yang persis sama seperti mereka?

Komputer Klien:

  • OS: Microsoft Windows Server 2019
  • Spesifikasi: Intel® Core™ i7-7700 (4C/8T), RAM 32GB, Kartu Ekspansi Jaringan QNAP 10GbE/25GbE/100GbE

Konfigurasi NAS:

  • OS: QTS 4.5.x & 5.0.0
  • Volume RAID: RAID 50 (8 bay ke atas), RAID 5 (4 bay hingga 6 bay), RAID 1 (2 bay), Single (1 bay)
  • SSD / HDD: Terisi penuh, 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: port Ethernet bawaan
  • Kartu Antarmuka Jaringan: 10GbE: Kartu Ekspansi Jaringan QNAP Dual-port 10 Gigabit (LAN-10G2T-U atau LAN-10G2SF-MLX)
  • Kartu Antarmuka Jaringan: 25GbE: Kartu Ekspansi Jaringan QNAP Dual-port 25 Gigabit (QXG-25G2SF-CX6)
  • Kartu Antarmuka Jaringan: 100GbE: Kartu Ekspansi Jaringan QNAP Dual-port 100 Gigabit (QXG-100G2SF-E810 atau QXG-100G2SF-CX6)

QNAP menggunakan ini sebagai sistem demo mereka

Tidak mungkin angka-angka itu bisa dicapai, saya bahkan hanya bisa mendapatkan 250MB\s dari 431XeU (1x SFP+)

Tentu saja saya tidak memiliki setup yang persis sama. Terutama mengingat setup yang dikutip situs tersebut bukanlah yang mereka uji (sebenarnya mustahil menurut saya karena TS-435XeU sudah memiliki 10GE bawaan tapi setahu saya tidak mendukung ekspansi NIC).

Yang benar (menurut saya) ada di sini:

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

Bagaimanapun juga, saya menjalankan versi S/W yang lebih baru daripada yang mereka uji (seperti yang diharapkan).

Komputer klien jelas bukan masalah (karena saya bisa mendapatkan 10gbps dengan menggunakan Mac kedua sebagai server SMB).

Perbedaan utama mungkin karena saya tidak memiliki setup RAID 4 x SSD (saya masih menggunakan HDD lama, meskipun yang 7200 RPM). Jadi ya - mungkin masalahnya di disk, meskipun saya berharap beban baca bisa dibagi ke beberapa disk…

Dari yang saya baca, M.2 SSD di TS435XeU bisa sangat panas jadi saya enggan memasangnya. Dan saya juga tidak terlalu ingin mengganti HDD dengan SSD…

Untuk mendapatkan kecepatan 10 Gb atau 2x 10 Gb ethernet, Anda benar-benar membutuhkan disk non spinning.

SSD yang diuji memiliki kecepatan 550 MB/s per disk, jadi dengan 4 disk mereka mampu mencapai 2235 MB/s seperti yang diklaim. Karena ini SSD, akses acak atau sekuensial tidak terlalu berpengaruh.

Anda belum membagikan konfigurasi Anda. RAID 10? 4 disk? Volume kosong? Thick? Snapshot? Performa baca? Performa tulis?

HDD cepat tidak akan memberikan lebih dari 220 MB/s dan dalam kasus terbaik Anda mungkin mendapatkan sekitar 800 MB/s? Namun jika Anda menggunakan bagian disk yang lambat, Anda hanya akan mendapatkan sekitar 300 MB/s atau sejenisnya.

Jika Anda memiliki snapshot atau volume tipis, Anda akan mendapatkan banyak i/o acak dan kecepatannya turun drastis. Bisa hanya 30 - 60 MB/s secara total.

ini adalah RAID 1 pada volume tebal.

Saya melihat 1.8gbps untuk baca dan 1.4gbps untuk tulis (yaitu 225MB/s dan 175MB/s masing-masing).

Disknya adalah Ironwolf Pros jadi seharusnya cukup cepat (saya pikir mereka mengklaim 220MB/s baca/tulis berkelanjutan)

Saya berharap bahwa pada RAID 1 saya bisa mendapatkan kecepatan baca hampir dua kali lipat dari satu disk karena cluster yang berbeda bisa dibaca dari disk yang berbeda - meskipun mungkin ada sedikit overhead seek saat disk bergerak dari akhir cluster N ke awal cluster N+2 setelah setiap baca?

Bagaimanapun, sepertinya SSD adalah jawabannya?

Data RAID1 dibaca dari kedua disk secara bersamaan, jadi tidak ada peningkatan kecepatan dibandingkan dengan satu disk.
Anda mungkin melihat peningkatan untuk pembacaan blok ganda (beberapa klien mengakses file yang berbeda)

Saya sudah memeriksa spesifikasi CPU dan TS-435XeU lebih baik daripada TS-433.

Pengaturan kamu tampaknya hampir sama dengan milik saya. Saya mendapatkan 220/160 dengan RAID1 2 disk IronWolf (non pro)

Saya berharap di RAID 1 saya bisa mendapatkan kecepatan baca hampir dua kali lipat dari satu disk karena cluster yang berbeda bisa dibaca dari disk yang berbeda - meskipun mungkin ada sedikit overhead seek saat disk berpindah dari akhir cluster N ke awal cluster N+2 setelah setiap pembacaan?

Di pengaturan saya, saya melihat ada sedikit peningkatan baca pada mirror. Tapi dengan level RAID lain, ini akan meningkat lebih banyak.

Bagaimanapun, sepertinya SSD adalah jawabannya?

Ya, SSD akan memberikan angka yang tinggi.