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 へ）。
- ハードウェアの変更は行われていません（ディスク交換なし、ケーブル交換なし、NIC 変更なし）。
- 設定の変更は行われていません（ファームウェア更新なし、ネットワーク設定変更なし、プロトコル変更なし）。
手順
ステップ 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: ネットワークパスを分離する（単一リンクテスト）
重要: リンクアグリゲーションやマルチパスを有効にした状態でテストしないでください。1 つの NIC → 1 つのケーブル → 1 つのスイッチポートを一度にテストしてください。
2a. NIC リンクネゴシエーションを確認する
- QTS / QuTS hero で、コントロールパネル → ネットワークと仮想スイッチ → インターフェースに移動し、各物理アダプターの速度とデュプレックスの値を確認します。
# （オプション）SSH を介して各インターフェースのネゴシエートされた速度とデュプレックスを確認する
ethtool eth0 | grep -E "Speed|Duplex|Link detected| 自動ネゴシエーション"
ethtool eth1 | grep -E "Speed|Duplex|Link detected| 自動ネゴシエーション"
# すべてのアクティブなインターフェース（eth2, eth3, ...）で繰り返します
- 10GbE NIC が 1GbE（またはそれ以下）にネゴシエートされた場合、スループットは約 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、スイッチ、クライアントの 3 つのエンドポイントは必ず同じ MTU を持つ必要があります。経路上のいずれかのデバイスが小さい MTU を持っている場合、パケットが断片化されたり、静かにドロップされる可能性があります。
- 簡易テスト: 一時的にすべてのデバイスで MTU を 1500（標準）に設定して再テストします。速度が改善される場合、問題はジャンボフレームの設定ミスである可能性があります。
- ジャンボフレーム (MTU 9000) は、NAS、スイッチポート、およびクライアント NIC のすべてで有効にする必要があります。
# NAS インターフェースを標準 MTU に一時的にリセットする（例） ifconfig eth0 mtu 1500 # クライアントからエンドツーエンドの MTU を確認するために ping でテストする 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 キャッシュを無効にすると、これに依存するワークロードのパフォーマンスが一時的に低下する可能性があります。可能であれば、メンテナンスウィンドウ中にこのテストを行ってください。
- 2 つの NAS ユニットを比較する際には、ファームウェアバージョン、インストールされたアプリケーション、NIC 設定、ボリューム設定がすべて同一であることを確認してください。
さらに読む
