Kecepatan rendah pada SMB - QES

Inggris Jaringan
1

Saat mengunduh/mengunggah file melalui protokol SMB ke folder bersama yang dibuat pada perangkat NAS yang disebutkan di atas, kecepatan transfer berkisar antara 180-200MB/s. Antara server NAS target dan komputer klien, terdapat sebuah switch yang konfigurasinya sepenuhnya mendukung kecepatan 10Gb/s. Saya ingin menyebutkan bahwa ekstensi 10GBase-T telah dipasang di kontroler SCA server NAS yang disebutkan di atas.

Saya telah memverifikasi status port yang digunakan untuk koneksi melalui koneksi SSH dan menggunakan perintah “ifcfg status eth8”.
Saya juga melakukan tes koneksi menggunakan iperf3. Saya menggunakan perintah “iperf3 -c -P 64”, yang mengonfirmasi bahwa koneksi mampu menangani ~10Gb/s.

Zrzut ekranu 2026-02-18 133957
Zrzut ekranu 2026-02-18 133957853Ă—1355 20.9 KB

Semua slot server NAS dan ekstensi telah terisi dengan disk, dari mana RAID5 dibuat, dan kemudian folder bersama dibuat menggunakan seluruh ruang dari RAID yang disebutkan di atas.

2

Saya tidak melihat perangkat yang disebutkan, hanya catatan tentang QES. Bisakah Anda menambahkan informasi ini (model dan firmware yang digunakan)

3

Hai @user712471326,

Terima kasih telah memberikan informasi teknis yang sangat rinci terkait performa SMB Anda pada sistem QES. Kami sangat menghargai upaya Anda dalam melakukan diagnostik iperf3 dan ifcfg, yang mengonfirmasi bahwa backbone jaringan 10GbE Anda berfungsi dengan sempurna.

Untuk membantu kami menyelidiki bottleneck throughput SMB ini (180-200MB/dtk) lebih lanjut, bisakah Anda memperjelas beberapa poin berikut?

  1. Linimasa masalah: Apakah kecepatan transfer sebelumnya normal, dan masalah ini baru saja terjadi? Atau sudah seperti ini sejak awal pemasangan?
  2. Pengujian lintas perangkat: Apakah Anda juga mengalami keterbatasan kecepatan yang sama saat terhubung dari komputer klien lain yang dilengkapi NIC 10GbE? Ini akan membantu kami menentukan apakah bottleneck terjadi pada satu klien saja atau pada konfigurasi NAS.

Mengingat kompleksitas lingkungan perangkat keras Anda (kontroler SCA dan RAID 5 pada QES), kami sangat menyarankan untuk membuka tiket dukungan resmi agar tim engineer senior kami dapat melakukan analisis lebih mendalam terhadap log sistem Anda.

Silakan kirim tiket di sini: https://service.qnap.com/

Salam hormat,
Tim Dukungan QNAP

4

Perangkatnya adalah Es1686dc R2 dengan firmware 2.2.1.2513 Build 20251126

5

Setelah konfigurasi awal, kami mulai mentransfer data dari server QNAP lama ke Es1686dc R2 baru dengan firmware 2.2.1.2513 Build 20251126. Jaringan berfungsi dengan sempurna selama beberapa hari pertama. Kecepatan mencapai 900-1000MB/s. Selama waktu tersebut, tidak ada perubahan konfigurasi pada server QNAP Es1686dc R2. Sekitar sebulan setelah peluncuran awal, masalah mulai muncul. Tim saya dan saya menguji apakah masalah tersebut terjadi pada mesin klien yang berbeda. Pada setiap perangkat, kecepatan tetap di sekitar 200MB/s meskipun menggunakan koneksi 10Gbps. Kami telah mencoba kabel yang berbeda, MTU 9000, dan standar SMB yang berbeda – namun tidak membuahkan hasil positif.

6

Jika Anda nyaman mengakses NAS Anda melalui SSH dan command line, ada beberapa hal yang mungkin ingin Anda periksa. Tidak ada perubahan yang dilakukan di sini – Anda hanya akan menggunakan antarmuka konsol untuk menanyakan status jaringan.

Yang pertama adalah

cat /sys/class/net/eth0/speed

[Jika Anda tidak menggunakan port jaringan eth0, Anda mungkin perlu mengganti nilai tersebut pada perintah di atas dengan port yang Anda gunakan.] Saya memiliki TVS672XT, yang memiliki port 10Gb bawaan, jadi ketika saya menjalankan perintah di atas, saya melihat “10000” sebagai respons. Ini akan memberi Anda keyakinan bahwa adaptor jaringan di NAS Anda, setidaknya, benar-benar berjalan pada 10Gb dan belum turun karena masalah lain [misalnya eksternal].

Perintah lain yang bisa Anda coba adalah:

ifconfig -a

Anda akan mendapatkan cukup banyak output dari ini, tetapi cukup mudah untuk melihat bahwa output tersebut dipecah menjadi blok untuk setiap adaptor fisik/virtual. Jika Anda dapat menemukan adaptor default [biasanya eth0], Anda bisa melihat pada baris ke-3 dan ke-4 dari output, di mana Anda akan mendapatkan indikasi jumlah error atau paket yang terbuang. Berikut hasil yang saya dapatkan di 672 saya saat mencoba perintah tersebut:

eth0 Link encap:Ethernet HWaddr 24:5E:BE:53:7F:06
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:222358095 errors:0 dropped:161 overruns:0 frame:0
TX packets:372509639 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:230092094401 (214.2 GiB) TX bytes:455412818198 (424.1 GiB)

Seperti yang Anda lihat, adaptor telah menjatuhkan 161 paket [dalam 31 hari, sejak reboot terakhir]. Jika Anda menemukan banyak error atau paket yang terbuang, itu bisa menjadi indikasi masalah yang lebih dalam.

Terakhir, dan saya mengerti ini mungkin tidak membantu Anda menemukan masalah yang tepat, tetapi mungkin bisa mengeliminasi archived protocol-related challenges, jika Anda memiliki akses ke host unix atau linux, Anda bisa mengaktifkan protokol jaringan NFS dan menguji performa melalui NFS daripada CIFS.

Microsoft Windows 11 Pro memang memiliki dukungan terintegrasi untuk NFS, tetapi harus diaktifkan sebelum course dapat digunakan. Silakan cari instruksinya di Google… Setelah Anda memiliki client NFS yang berfungsi di workstation Anda dan telah mengaktifkan NFS melalui Control Panel, Anda sekarang se covering dapat melakukan pengujian berdampingan menggunakan dua protokol jaringan yang berbeda. Jika Anda melihat adanya perbedaan di sini, maka itu menunjukkan adanya error pada protokol, sedangkan jika Anda mendapatkan hasil yang sama atau sangat mirip, itu menunjukkan bahwa masalah Anda ada pada lapisan transport atau fisik dari koneksi Anda…

Akhirnya, deskripsi masalah awal Anda menunjukkan bahwa performa awalnya baik-baik saja tetapi kemudian menurun. Jika perubahannya tiba-tiba, itu mungkin akibat dari perubahan yang dilakukan di suatu tempat – “perubahan” di sini bisa berarti “seseorang memindahkan kabel dan meninggalkan koneksi yang marginal”… atau bisa juga berarti perubahan konfigurasi teknis yang sebenarnya. Jika perubahannya berupa penurunan yang lambat, itu bisa jadi menunjukkan adanya pengurasan sumber daya secara perlahan, memory leak, atau hal semacam itu. Anda bisa mencoba mengeliminasi kemungkinan itu dengan me-reboot semua perangkat [NAS, host, dan perangkat jaringan] di rangkaian. Sekali lagi, ini mungkin tidak menemukan masalahnya, tetapi bisa membantu mempersempit area pencarian Anda…

7

Saat terhubung ke server melalui SSH, kita menggunakan perintah yang berbeda dari yang digunakan di QTS. Di sini, saya memiliki perintah “ifcfg”. Menambahkan, misalnya, variabel “status eth8” akan mengembalikan informasi berikut:

image
image381Ă—305 9.47 KB

8

Oke, dari sini kita bisa mengambil beberapa hal… Pada level perangkat keras, Anda jelas sudah berjalan di 10Gb/s - setidaknya dari NAS ke switch Anda. Juga, dari pengaturan “MTU … 9000”, kita bisa lihat bahwa Anda telah mengaktifkan frame “jumbo” - yang memang diinginkan untuk performa optimal pada jaringan 10Gb/s.

Ini tentu saja belum bisa disimpulkan… tapi Anda sudah berhasil mengeliminasi potensi masalah.

Jika Anda bisa melakukan pengecekan serupa di “ujung lain” dari transfer ini dan bisa memastikan bahwa mereka juga sudah diatur ke 10Gb… maka langkah selanjutnya kemungkinan adalah melihat data error/paket yang terbuang… dan/atau mengonfigurasi kedua host untuk menggunakan NFS dan menjalankan perbandingan secara berdampingan.

Pengalaman saya sudah lama… tapi saya pikir NFS seharusnya lebih efisien “di jaringan” dibandingkan dengan CIFS, karena yang terakhir “sedikit lebih ramai” dalam komunikasi. Tapi data itu berasal dari lebih dari 10 tahun lalu - NFSv4 dan apapun versi CIFS terbaru mungkin sudah mengubah hal itu.

9

Saya tertarik dengan fakta bahwa kecepatan awalnya adalah 10Gbps. Kami bertanya-tanya apakah hal ini disebabkan oleh kurangnya dukungan untuk SMB Multichannel.

https://www.qnap.com/en/how-to/faq/article/does-qes-support-smb-multichannel

10

Saya akan cenderung untuk menyingkirkan pertanyaan ini terlebih dahulu—setidaknya pada awalnya—karena Anda menggambarkan masalah di mana performa menurun seiring waktu. Masalah kompatibilitas—setidaknya yang saya ketahui—cenderung bersifat biner: sesuatu entah berfungsi atau tidak. Saya tentu tidak berharap melihat kompatibilitas sebagai penyebab utama berdasarkan pernyataan masalah Anda.

Saya pikir kita perlu kembali fokus pada deskripsi Anda tentang “apa yang merupakan” dan “apa yang bukan” masalahnya.

Mari kita coba persempit ruang lingkupnya sedikit lagi…

  1. Apakah Anda memiliki perangkat NAS atau server lain di jaringan Anda yang dapat strictly Anda uji terhadap klien Anda, sehingga Anda benar-benar bisa memastikan masalahnya ada pada satu perangkat tertentu?
  2. Bisakah Anda membuat atau menetapkan semacam pengujian empiris yang dapat diulang untuk mendapatkan hasil tes kecepatan yang objektif? Misalnya, Anda mungkin bisa men standingkan sebuah skrip shell Windows yang mengatur waktu ke nol; menyalin satu atau lebih file dari NAS ke host [atau host ke NAS] lalu mencatat waktu yang dibutuhkan. Akan sangat membantu jika Anda memiliki skrip shell sederhana yang bisa diulang secara objektif, di host yang berbeda dan pada waktu yang berbeda.
  3. Rasanya wajar jika perangkat Anda terhubung melalui beberapa perangkat jaringan sebagai penghubung—dan mungkin Anda memiliki satu atau lebih switch ethernet [misalnya] antara workstation dan NAS. Ada beberapa hal di sini… Pertama, apakah Anda punya cara untuk secara fisik memindahkan mesin klien ke lokasi yang sama dengan NAS sehingga Anda bisa mengulang tes dan mengeliminasi semua jaringan perantara? Kedua, apakah perangkat jaringan Anda managed atau un-managed? Jika yang pertama, mungkin Anda bisa mendapatkan metrik performa yang berguna jika Anda punya workstation SNMP dan bisa menarik data dari perangkat jaringan Anda.
  4. Pada QNAP NAS Anda, lagi-lagi lewat SSH, coba jalankan “ethtool”—Anda bisa mencari di Google untuk artikel tentang arti semua opsi command line dan bagaimana mengurutkannya untuk mendapatkan data… Di Windows, Anda bisa menggunakan Powershell dan “Get-NetAdapterStatistics” untuk mengetahui apa yang sistem operasi lokal Anda pikirkan tentang performa adapter jaringan workstation Anda…
  5. Saya sudah menyebutkannya, tapi saya pikir akan membantu jika Anda bisa menguji protokol non-CIFS antara host yang dimaksud. Saya sarankan NFS—dan mengatur NAS Anda untuk melayani permintaan koneksi NFS [pastikan versinya diatur dengan benar] akan menjadi awal yang baik. Jika tidak, mungkin pertimbangkan menggunakan ftp atau sftp?
  6. Keenam adalah hal yang jelas—perubahan. Fakta bahwa masalah muncul setelah Anda menjalankan sistem dengan sukses untuk beberapa waktu sangat menunjukkan bahwa ada sesuatu yang berubah. Anda tidak mendeskripsikan ukuran organisasi Anda atau seberapa ketat Anda mengatur perubahan teknologi… jadi mungkinkah ada masalah yang muncul dari sesuatu yang hanya secara tidak langsung berkaitan dengan area fokus utama Anda. Mungkin periksa log perubahan Anda atau bicara dengan orang lain yang mengelola lingkungan Anda?
  7. Ketujuh adalah reliabilitas… bukan pada NAS [yang cukup on atau off dalam hal itu] tapi apakah Anda, misalnya, punya hard drive yang bermasalah? Apakah NAS Anda diatur untuk mengirim peringatan secara eksternal jika mendeteksi masalah pada hard drive? Apakah Anda sudah mendapat laporan kesehatan yang bersih dari pemantauan S.M.A.R.T.?
  8. Kedelapan adalah utilisasi jaringan Anda. Apakah Anda punya cara untuk memeriksa apakah ada sesuatu di jaringan yang menyedot bandwidth sehingga NAS Anda kesulitan mengirim paket? Inilah alasan saya pikir mungkin tempat pertama untuk memulai adalah dengan membawa workstation klien dan NAS Anda secara fisik bersama—pindahkan workstation ke tempat yang sama dengan NAS. Sementara, colokkan mereka ke switch sehingga hanya ada 2 perangkat yang terhubung dan ulangi tes performa Anda. Jika gagal, Anda tahu masalahnya ada pada salah satu perangkat Anda; jika berhasil, maka Anda bisa “mundur”—memindahkan workstation secara bertahap lebih jauh sampai performa menurun.
  9. Sekarang kita masuk ke kemungkinan penyebab yang lebih esoterik… Sudahkah Anda melihat bagaimana performa workstation Anda terkait misalnya dengan ambang “Remote File Dirt Page”? Ini bisa menyebabkan masalah seperti yang Anda lihat. Pada dasarnya, klien Windows memiliki pengaturan buffer default [biasanya sekitar 5Gb] untuk data “dirty” dan “unsaved”. Setelah ambang itu terlampaui, sistem berhenti menerima data masuk sampai yang ada ditulis ke disk. Ada parameter Registry, “RemoteFileDirtyPageThreshold” di Registry [Google bisa membantu, dll] yang bisa Anda atur di kedua sisi pengujian, hanya untuk melihat apakah itu membuat perbedaan.
  10. Jika Anda belum melakukannya, pastikan juga bertanya ke komunitas dukungan Microsoft—komunitasnya jauh lebih besar [untuk alasan yang jelas] dan ada kemungkinan seseorang di sana pernah melihat sesuatu yang mirip dengan yang Anda deskripsikan di sini.

Saya sadar apa yang saya jabarkan di atas agak seperti pendekatan “scatter-gun” [saya berusaha mengurutkan tes secara logis]. Semoga, meskipun Anda tidak bisa langsung mengikuti semua di atas, saya sudah memberi Anda beberapa ide yang bisa Anda tindak lanjuti…

11

SMB multi-channel digunakan ketika Anda memiliki beberapa NIC dan ingin mendapatkan koneksi yang lebih cepat. Jadi jika Anda memiliki dua NIC 2,5 Gbit/dtk, Anda dapat menggunakan keduanya untuk mentransfer data melalui koneksi SMB.

Anda juga bisa melakukannya dengan dua atau lebih koneksi 10 Gbps, tetapi sepertinya itu bukan masalah Anda. Menurut saya, Anda tidak mendapatkan kecepatan yang diharapkan pada satu koneksi 10 Gbps dan multi-channel tidak akan membantu.

12

Kami memiliki satu lagi server NAS QNAP QTS Hero lama yang terhubung ke jaringan. Kecepatan penyalinan file ke/dari server melalui SMB mencapai nilai yang diharapkan yaitu 1GB/dtk.

Kami menghubungkan stasiun pengujian langsung ke port 10Gbps pada server NAS es1686dc R2. Meskipun koneksi langsung tanpa switch, kecepatan transfer tetap berfluktuasi di sekitar 200MB/dtk.

QNAP ini tidak memiliki perintah “ethtool”. Berikut adalah daftar perintah yang tersedia.

Zrzut ekranu 2026-02-25 113931
Zrzut ekranu 2026-02-25 113931756Ă—245 7.49 KB

Saya telah melakukan pengujian SMART - semua drive berfungsi, dan saya juga meninjau log kejadian - tidak ada error/peringatan.

Saya menguji koneksi FTP - hasilnya lebih buruk dibandingkan dengan SMB, yaitu sekitar 95MB/dtk.

Pada salah satu dari lebih dari 30 komputer, kami mengalami situasi di mana kecepatan melebihi 200MB/dtk. Lebih spesifiknya, kecepatan mencapai sekitar 600MB/dtk, tetapi kecepatannya tidak stabil, yaitu berfluktuasi antara 300-600MB/dtk - benar-benar tidak ada kestabilan koneksi.

13

Periksa kecepatan menggunakan iperf langsung dari QNAP ke PC target. Jika Anda hanya mencapai 10G di sana, itu disebabkan oleh faktor-faktor seperti:

  1. Jenis dan jumlah file (ukuran)

  2. Apa saja yang sedang berjalan di NAS atau PC

  3. Ukuran cache tulis pada PC target. Dengan beberapa gigabyte dalam beberapa file, Anda dapat mencapai kecepatan maksimum.

Apa pun yang perlu dibaca dari NAS sebelum dapat ditransfer akan sangat mengurangi kecepatan transfer. Hal yang sama berlaku jika cache tulis pada PC penuh.

Jika Anda ingin mentransfer banyak data, sekitar 500MB/dtk adalah realistis.

Saya telah menguji ini dengan banyak QNAP, PC, server, dan sistem penyimpanan di seluruh dunia.

– diterjemahkan ke bahasa Indonesia seperti yang diposting "Mr worldwide" dalam bahasa Jerman–

14

Pada pesan pertama, saya telah memaparkan hasil iperf3. Koneksi memungkinkan untuk 10Gbps. Jumlah dan ukuran file tidak berpengaruh, karena saat mencoba mengirim/mengunduh satu file berukuran 100-500GB, kecepatan tetap stabil di sekitar 200MB/s.

16

periksa di qnap, storage dan snapshots, overview, pilih sebuah disk, cek Kesehatan Disk, Advanced bahwa NCQ pada semua disk AKTIF

juga periksa bahwa semua antarmuka 10gbit Anda - komputer dan qnap berada pada 10Gbit dan bukan 2.5Gbit

17

juga untuk menguji kecepatan koneksi, kami selalu menggunakan sebagai referensi perangkat lunak Blackmagic Speedtest gratis = pengujian antarmuka DAN disk. - juga periksa bahwa tidak ada proses rebuild yang sedang berjalan di QNAP, karena itu juga membatasi kecepatan selama rebuild - tergantung pada kecepatan rebuild

18

Hai semua. Setelah berjuang dengan masalah ini selama beberapa hari, kami telah menemukan solusi parsial. Pertama, saya harus menyebutkan bahwa kami telah me-reboot ES1686DC R2. Kami membuat berbagai konfigurasi pool dan RAID dengan setiap kemungkinan pengaturan shared folder. Kami mengganti switch, pengaturan pada switch, serta kabel dan komputer klien. Selain itu, NAS kedua, TS-h1277AXU-RP, terhubung ke jaringan sepanjang waktu, dan telah menggunakan kecepatan jaringan penuh (10Gbps) tanpa masalah sedikit pun.

Bersama tim, kami menemukan situasi yang menarik. Setelah menggunakan perintah
untuk menonaktifkan SMB signature di sisi klien, yaitu,

Set-SmbClientConfiguration -RequireSecuritySignature $false

kecepatan meningkat dari 200MB/s menjadi 650MB/s. Namun, kami masih belum dapat sepenuhnya menyelesaikan masalah ini. Apakah ada yang pernah mengalami masalah terkait SMB signing?

Saya akan menambahkan beberapa informasi mengenai komputer klien.
Windows 11 Pro (25H2)
ASUS ProArt X870E
AMD Ryzen 9 9950X
192GB RAM
Kartu Jaringan: Aquantia/Marvell AQC113 FastLinQ Edge 10Gbit Network Adapter
Drive: 3x Samsung SSD 9100 PRO 4TB

1 Suka