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：隔离网络路径（单链路测试）
重要：不要在链路聚合或多路径激活时测试。一次测试一个网卡→一根电缆→一个交换机端口。
2a. 检查网卡链路协商
- 在 QTS / QuTS hero 中，进入控制台 → 网络与虚拟交换机 → 接口，并验证每个物理适配器的速度和双工值。
# （可选）通过 SSH 检查每个接口的协商速度和双工
ethtool eth0 | grep -E "Speed|Duplex|Link detected| 自动协商"
ethtool eth1 | grep -E "Speed|Duplex|Link detected| 自动协商"
# 对所有活动接口重复（eth2, eth3, ...）
- 协商降至 1GbE（或更低）的 10GbE 网卡将把吞吐量限制在大约 117 MB/s。
- 半双工协商会降低吞吐量并导致冲突。
- 如果自动协商显示速度异常，请尝试更换电缆或交换机端口。
2b. 检查接口错误计数器
# 检查数据包错误、丢弃和溢出
ifconfig eth0 | grep -E "errors|dropped|overruns|frame|carrier"
# 或使用 ip -s:
ip -s link show eth0
- 非零接收错误、发送错误、丢弃或溢出可能表示电缆、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、绑定和交换机配置。
- 仅查看 SMB 结果不足以确定根本原因——如果所有协议都很慢，首先执行网络层隔离。
dd写入测试会在卷上创建一个临时文件——确保有足够的可用空间，并在之后清理。- 在生产系统上禁用 SSD 缓存可能会暂时降低依赖它的工作负载的性能。如有可能，请在维护窗口期间进行此测试。
- 在比较两个 NAS 设备时，确保固件版本、已安装的应用程序、NIC 配置和卷配置相同。
进一步阅读
