이 콘텐츠는 기계 번역된 것입니다. 기계 번역 부인정보를 참조하십시오.

영어로 전환

How do I troubleshoot it if my NAS transfer speeds dropped dramatically ?

NAS 전송 속도가 급격히 떨어졌을 때 문제를 해결하려면 어떻게 해야 합니까?

최신 업데이트일: 2026-03-31

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.

적용되는 제품

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)

NAS에iperf3가 설치되어 있지 않다면, 단계별 설치 지침은 QNAP FAQ QTS와 QuTS hero에 iperf3를 설치하려면 어떻게 해야 합니까?를 참조하십시오. 또는 같은 스위치 세그먼트에 있는 두 클라이언트 PC 간에iperf3를 실행하여 스위치 및 케이블 성능을 확인할 수 있습니다.

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, ...)에 대해 반복

10GbE NIC가 1GbE(또는 그 이하)로 협상된 경우처리량는 약 117 MB/s로 제한됩니다.
하프 듀플렉스 협상은처리량를 크게 줄이고 충돌을 일으킬 수 있습니다.
자동 협상가 예상치 못한 속도를 표시하는 경우 다른 케이블이나 스위치 포트를 시도하십시오.

2b. 인터페이스 오류 카운터 확인

# 패킷 오류, 드롭 및 오버런 확인
ifconfig eth0 | grep -E "errors|dropped|overruns|frame|carrier"
# 또는 ip -s 사용:
ip -s link show eth0

0이 아닌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(표준)으로 임시 설정하고 다시 테스트합니다. 속도가 개선되면 문제는점보 프레임잘못된 구성일 가능성이 높습니다.
NAS, 스위치 포트, 그리고클라이언트 NIC에서점보 프레임 (MTU 9000)이 활성화되어야 합니다 — 모두 세 가지.

# NAS 인터페이스를 표준 MTU로 임시 재설정 (예시) ifconfig eth0 mtu 1500  # 클라이언트에서 끝에서 끝까지 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 구성 및 볼륨 구성이 모두 동일한지 확인하십시오.

추가 읽기

이 기사가 도움이 되었습니까?

예. 아니요.

50% 의 사용자들이 도움이 된다고 생각할 것입니다.

추가 도움이 필요하시면 커뮤니티에서 다른 사용자 및 QNAP 전문가에게 문의해 보세요. QNAP 커뮤니티로 이동

이 기사가 어떻게 개선될 수 있을지 말해 주십시오.

기사에 중요한 정보가 없습니다
기사의 솔루션이 작동하지 않습니다
기사가 너무 복잡합니다
기사에 잘못된 정보가 있습니다
기사가 오래되었습니다

추가 피드백을 제공하려면 아래에 포함하십시오.