Applicable Products
- All QNAP NAS models running QTS / QuTS hero
Symptom
- NAS transfer speeds dropped dramatically (for example, from several hundred MB/s down to tens of MB/s).
- No hardware changes were made (no disk replacement, no cable swap, no NIC change).
- No configuration changes were made (no firmware update, no network setting change, no protocol change).
Procedure
Step 1: Test pure network throughput (iperf3)
Verify the network link independently of any file protocol. This is the most important first test.
# On the NAS (start iperf3 server)
iperf3 -s
# On the client PC (single stream)
iperf3 -c <NAS_IP> -t 10
# On the client PC (multi-stream for aggregation testing)
iperf3 -c <NAS_IP> -t 10 -P 4
| Link type | Expected iperf3 result |
|---|
| 1GbE | ~940 Mbps (~117 MB/s) |
| 10GbE | ~9.4 Gbps (~1.17 GB/s) |
| 25GbE | ~23.5 Gbps (~2.9 GB/s) |
If
iperf3 is not installed on your NAS, see the QNAP FAQ
How do I install iperf3 in QTS and QuTS hero? for step-by-step installation instructions. Alternatively, you can run
iperf3 between two client PCs on the same switch segment to verify switch and cabling performance.
- If the iperf3 result is also low, the network path is the bottleneck. Proceed to Step 2.
- If the iperf3 result is normal, the physical network is likely fine; the problem is in the file service layer. Skip to Step 4.
Step 2: Isolate the network path (single link testing)
Important: Do not test with link aggregation or multipathing active. Test one NIC → one cable → one switch port at a time.
2a. Check NIC link negotiation
- In QTS / QuTS hero, go to Control Panel → Network & Virtual Switch → Interfaces and verify the Speed and Duplex values for each physical adapter.
# (Optional) Check negotiated speed and duplex for each interface via SSH
ethtool eth0 | grep -E "Speed|Duplex|Link detected|Auto-negotiation"
ethtool eth1 | grep -E "Speed|Duplex|Link detected|Auto-negotiation"
# Repeat for all active interfaces (eth2, eth3, ...)
- A 10GbE NIC that has negotiated down to 1GbE (or lower) will cap throughput at approximately 117 MB/s.
- Half-duplex negotiation can significantly reduce throughput and cause collisions.
- If auto-negotiation shows an unexpected speed, try a different cable or switch port.
2b. Check interface error counters
# Check for packet errors, drops, and overruns
ifconfig eth0 | grep -E "errors|dropped|overruns|frame|carrier"
# Or use ip -s:
ip -s link show eth0
- Non-zero RX errors, TX errors, dropped, or overruns can indicate cable, SFP, or switch port problems.
- Run the check before and after a large transfer to see if counters increase.
2c. Test cable and SFP/DAC module(if used)
- Swap the DAC cable or SFP module with a known-good one.
- Connect the NAS directly to the client PC (bypassing the switch) to isolate switch issues.
- Try a different switch port.
- If using fiber SFP+, check for dirty connectors or bent fibers.
Step 3: Verify MTU consistency (jumbo frames)
MTU mismatch between NAS, switch, and client is a common cause of throughput collapse.
# Check MTU on NAS interfaces
ip link show | grep mtu
# Check MTU on client (Windows)
netsh interface ipv4 show subinterfaces
# Check MTU on client (Linux / macOS)
ifconfig | grep mtu
All three endpoints (NAS, switch, client) must have the same MTU. If any device in the path has a smaller MTU, packets can be fragmented or dropped silently.
- Quick test: Temporarily set MTU to 1500 (standard) on all devices and re-test. If speed improves, the issue is likely jumbo frame misconfiguration.
- Jumbo frames (MTU 9000) must be enabled on the NAS, the switch port, and the client NIC — all three.
# Temporarily reset NAS interface to standard MTU (example)
ifconfig eth0 mtu 1500
# Test with ping to verify end-to-end MTU (from client)
ping -f -l 8972 <NAS_IP> # Windows (8972 = 9000 - 28 headers)
ping -M do -s 8972 <NAS_IP> # Linux
Step 4: Check background tasks and system load
Common cause of periodic slowdowns: Scheduled pool scrubbing and scheduled backup jobs can consume significant disk I/O and cause transfer speeds to drop dramatically while they are running. If the speed issue occurs at predictable intervals (for example, weekly or nightly), check the schedules first.
4a. Check scheduled pool scrubbing
- In QTS / QuTS hero, go to Storage & Snapshots → Storage/Snapshots, select the storage pool, and then click Manage → Actions to check the scrubbing schedule.
- RAID scrubbing reads every block on every disk in the array — this can reduce transfer performance by 50% or more while running.
- QTS defaults may schedule scrubbing periodically (for example, monthly); QuTS hero (ZFS) also has its own scrub schedule.
# Check for active RAID scrubbing or rebuild
cat /proc/mdstat | grep -E "resync|recovery|reshape|check"
# Check ZFS scrub status (QuTS hero)
zpool status | grep -E "scan|scrub"
4b. Check scheduled backup jobs
- HBS 3 (Hybrid Backup Sync), RTRR, rsync, and Snapshot Replica jobs can saturate disk I/O or network bandwidth when running.
- In QTS / QuTS hero, open HBS 3 and check active and scheduled jobs; also check any third-party backup software.
- If a backup job runs at the same time as user file transfers, both will compete for I/O.
Step 5: Verify storage layer (confirmation)
If all network tests pass, confirm that the storage layer is not the bottleneck.
# Quick RAID health check
cat /proc/mdstat
# Storage performance test
qcli_storage -t
# Local filesystem throughput (bypasses network entirely)
dd if=/dev/zero of=/share/CACHEDEV1_DATA/testfile bs=1M count=1024 oflag=direct
dd if=/share/CACHEDEV1_DATA/testfile of=/dev/null bs=1M iflag=direct
rm /share/CACHEDEV1_DATA/testfile
- If local
dd throughput is also low, check SSD cache status (Storage & Snapshots → Cache Acceleration) — a degraded cache can throttle I/O. - Check S.M.A.R.T. health if disk throughput appears abnormal.
Step 6: Collect diagnostic data for support
If the above steps do not resolve the issue, collect these data and dump the system log before opening a support ticket.
Open a support ticket at https://service.qnap.com/ and attach the output.
Warnings
- Do not make multiple changes simultaneously — change one variable at a time and re-test.
- Record original settings before making changes, especially network, MTU, bonding, and switch configuration.
- Looking at SMB results alone is not sufficient to determine the root cause — if all protocols are slow, perform network-layer isolation first.
- The
dd write test creates a temporary file on the volume — ensure adequate free space and clean up afterward. - Disabling SSD cache on a production system may temporarily reduce performance for workloads that rely on it. If possible, perform this test during a maintenance window.
- When comparing two NAS units, ensure firmware version, installed applications, NIC configuration, and volume configuration are all identical.
Further Reading
適用產品
- All QNAP NAS models running QTS / QuTS hero
症狀
- NAS 傳輸速度急劇下降（例如，從數百 MB/s 降至數十 MB/s）。
- 未進行硬體更換（未更換磁碟、未更換纜線、未更換網路介面卡）。
- 未進行設定更改（未更改韌體更新、未更改網路設定、未更改協定）。
程式
步驟 1：測試純網路輸送量（iperf3）
獨立於任何檔案協定驗證網路連結。這是最重要的第一步測試。
# 在 NAS 上（啟動 iperf3 伺服器） iperf3 -s # 在客戶端 PC 上（單一流） iperf3 -c <nas_ip> -t 10 # 在客戶端 PC 上（多流以進行聚合測試） iperf3 -c <nas_ip> -t 10 -P 4
| 連結型別 | 預期的 iperf3 結果 |
|---|
| 1GbE | ~940 Mbps (~117 MB/s) |
| 10GbE | ~9.4 Gbps (~1.17 GB/s) |
| 25GbE | ~23.5 Gbps (~2.9 GB/s) |
- 如果 iperf3 結果也很低，則網路路徑是瓶頸。請進行步驟 2。
- 如果 iperf3 結果是正常，則物理網路可能良好；問題在於檔案服務層。跳至步驟 4。
步驟 2：隔離網路路徑（單一連結測試）
重要：請勿在連結聚合或多路徑啟用時進行測試。一次測試一個 NIC → 一條線 → 一個交換機埠。
2a. 檢查 NIC 連結協商
- 在 QTS / QuTS hero，前往控制台 → 網路與虛擬交換器 → 介面，並驗證每個實體適配器的速度和雙工值。
# （可選）透過 SSH 檢查每個介面的協商速度和雙工
ethtool eth0 | grep -E "Speed|Duplex|Link detected| 自動協調"
ethtool eth1 | grep -E "Speed|Duplex|Link detected| 自動協調"
# 重複所有活躍介面（eth2, eth3, ...）
- 協商降至 1GbE（或更低）的 10GbE NIC 將使輸送量限制在約 117 MB/s。
- 半雙工協商可能會顯著降低輸送量並導致碰撞。
- 如果自動協調顯示意外速度，請嘗試不同的線材或交換機埠。
2b. 檢查介面錯誤計數器
# 檢查封包錯誤、丟失和超限
ifconfig eth0 | grep -E "errors|dropped|overruns|frame|carrier"
# 或使用 ip -s:
ip -s link show eth0
- 非零RX 錯誤、TX 錯誤、丟失或超限可能表示線材、SFP 或交換機埠問題。
- 在大檔案傳輸前後執行檢查以檢視計數器是否增加。
2c. 測試線材和 SFP/DAC 模組（如果使用）
- 將 DAC 線材或 SFP 模組替換為已知良好的。
- 將 NAS 直接連線到客戶端 PC（繞過交換機）以隔離交換機問題。
- 嘗試不同的交換機埠。
- 如果使用光纖 SFP+，檢查接頭是否髒汙或光纖是否彎曲。
步驟 3：驗證 MTU 一致性 (巨型訊框)
NAS、交換機和客戶端之間的 MTU 不匹配是輸送量崩潰的常見原因。
# 檢查 NAS 介面的 MTU
ip link show | grep mtu
# 檢查客戶端的 MTU (Windows)
netsh interface ipv4 show subinterfaces
# 檢查客戶端的 MTU (Linux / macOS)
ifconfig | grep mtu
所有三個端點（NAS、交換機、客戶端）必須具有相同的 MTU。如果路徑中的任何設備具有較小的 MTU，封包可能會被分段或靜默丟棄。
- 快速測試：暫時將所有設備的 MTU 設為 1500（標準）並重新測試。如果速度改善，問題可能是巨型訊框配置錯誤。
- 巨型訊框（MTU 9000）必須在 NAS、交換機埠、以及客戶端 NIC 上啟用——所有三者。
# 暫時將 NAS 介面重置為標準 MTU（範例） ifconfig eth0 mtu 1500 # 使用 ping 測試以驗證端到端 MTU（從客戶端） ping -f -l 8972 <nas_ip> # Windows (8972 = 9000 - 28 headers) ping -M do -s 8972 <nas_ip> # Linux
步驟 4：檢查背景任務和系統負載
週期性速度變慢的常見原因：排程的儲存池檢查和排程備份工作可能會消耗大量磁碟 I/O，並在執行時導致傳輸速度急劇下降。如果速度問題在可預測的時間間隔（例如，每週或每晚）發生，請先檢查排程。
4a. 檢查排程的儲存池檢查
- 在 QTS / QuTS hero 中，前往儲存與快照總管 → 儲存空間 / 快照，選擇儲存空間儲存池，然後點擊管理 → 動作以檢查檢查排程。
- RAID 檢查會讀取陣列中每個磁碟上的每個區塊——這可能會在執行時使傳輸效能降低 50% 或更多。
- QTS 預設可能會定期排程檢查（例如，每月）；QuTS hero（ZFS）也有自己的檢查排程。
# 檢查是否有活動的 RAID 檢查或重建
cat /proc/mdstat | grep -E "resync|recovery|reshape|check"
# 檢查 ZFS 檢查狀態 (QuTS hero)
zpool status | grep -E "scan|scrub"
4b. 檢查排程的備份工作
- HBS 3 (Hybrid Backup Sync)、RTRR、rsync 和快照備份任務工作在執行時可能會耗盡磁碟 I/O 或網路頻寬。
- 在 QTS / QuTS hero 中，打開HBS 3並檢查活動和排程的工作；也檢查任何第三方備份軟體。
- 如果備份工作與使用者檔案傳輸同時進行，兩者將競爭 I/O。
步驟 5：驗證儲存空間層（確認）
如果所有網路測試都通過，確認儲存空間層不是瓶頸。
# 快速 RAID 健康檢查
cat /proc/mdstat
# 儲存空間性能測試
qcli_儲存空間 -t
# 本地檔案系統輸送量（完全繞過網路）
dd if=/dev/zero of=/share/CACHEDEV1_DATA/testfile bs=1M count=1024 oflag=direct
dd if=/share/CACHEDEV1_DATA/testfile of=/dev/null bs=1M iflag=direct
rm /share/CACHEDEV1_DATA/testfile
- 如果本地
dd 輸送量也很低，檢查 SSD 快取狀態（儲存與快照總管 → 快取加速）— 降級的快取可能會限制 I/O。 - 如果磁碟輸送量顯示異常，檢查 S.M.A.R.T. 健康狀態。
步驟 6：收集診斷資料以供支援
如果上述步驟未解決問題，請收集這些資料並在開啟支援票證前傾印系統記錄。
在https://service.qnap.com/開啟支援票證並附上輸出。
警告
- 不要同時進行多項變更——一次只更改一個變數並重新測試。
- 在進行變更前記錄原始設定，尤其是網路、MTU、Bonding 和交換機設定。
- 僅檢視 SMB 結果不足以判斷根本原因——如果所有協定都很慢，請先進行網路層隔離。
dd寫入測試會在磁碟區上建立暫存檔案——確保有足夠的可用空間並在完成後清理。- 在生產系統上停用 SSD 快取可能會暫時降低依賴它的工作負載性能。如有可能，請在維護時段進行此測試。
- 在比較兩台 NAS 設備時，請確保韌體版本、已安裝的應用程式、NIC 設定和磁碟區設定完全相同。
進一步閱讀
