เนื้อหานี้ได้รับการแปลด้วยเครื่อง กรุณาดูที่คำแถลงการณ์ปฏิเสธความรับผิดชอบของการแปลภาษาด้วยเครื่อง

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

ฉันจะแก้ไขปัญหาอย่างไรหากความเร็วในการถ่ายโอนข้อมูล NAS ของฉันลดลงอย่างมาก?

Last modified date: 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)

หาก iperf3 ไม่ได้ติดตั้งบน NAS ของคุณ ดูคำแนะนำการติดตั้งทีละขั้นตอนใน QNAP FAQ ฉันจะติดตั้ง iperf3 ใน QTS และ QuTS hero ได้อย่างไร? หรือคุณสามารถเรียกใช้ iperf3 ระหว่าง PC ลูกค้าสองเครื่องในเซ็กเมนต์สวิตช์เดียวกันเพื่อทดสอบประสิทธิภาพของสวิตช์และสายเคเบิล

หากผลลัพธ์ iperf3 ต่ำ เส้นทาง เครือข่ายเป็นคอขวด ดำเนินการต่อไปยังขั้นตอนที่ 2
หากผลลัพธ์ iperf3 เป็น ปกติ เครือข่ายทางกายภาพน่าจะไม่มีปัญหา ปัญหาอยู่ที่ชั้นบริการไฟล์ ข้ามไปที่ขั้นตอนที่ 4

ขั้นตอนที่ 2: แยกเส้นทางเครือข่าย (การทดสอบลิงก์เดียว)

สำคัญ: อย่าทดสอบด้วยการรวมลิงก์หรือการใช้หลายเส้นทาง ทดสอบ NIC หนึ่งตัว → สายเคเบิลหนึ่งเส้น → พอร์ตสวิตช์หนึ่งพอร์ตในแต่ละครั้ง

2a. ตรวจสอบการเจรจาลิงก์ NIC

ใน QTS / QuTS hero ไปที่ แผงควบคุม → เครือข่ายและสวิตช์เสมือน → อินเทอร์เฟซ และตรวจสอบค่า ความเร็ว และ ดูเพล็กซ์ สำหรับอะแดปเตอร์ทางกายภาพแต่ละตัว

# (ตัวเลือก) ตรวจสอบความเร็วและดูเพล็กซ์ที่เจรจาสำหรับแต่ละอินเทอร์เฟซผ่าน SSH
ethtool eth0 | grep -E "Speed|Duplex|Link detected|การเจรจาอัตโนมัติ (Auto-Negotiation)"
ethtool eth1 | grep -E "Speed|Duplex|Link detected|การเจรจาอัตโนมัติ (Auto-Negotiation)"
# ทำซ้ำสำหรับอินเทอร์เฟซที่ใช้งานอยู่ทั้งหมด (eth2, eth3, ...)

NIC 10GbE ที่เจรจาลงไปที่ 1GbE (หรือต่ำกว่า) จะจำกัด อัตราความเร็ว ไว้ที่ประมาณ 117 MB/s
การเจรจาแบบดูเพล็กซ์ครึ่งหนึ่งสามารถลด อัตราความเร็ว ได้อย่างมากและทำให้เกิดการชนกัน
หาก การเจรจาอัตโนมัติ (Auto-Negotiation) แสดงความเร็วที่ไม่คาดคิด ลองใช้สายเคเบิลหรือพอร์ตสวิตช์อื่น

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 (Jumbo Frame)

การไม่ตรงกันของ MTU ระหว่าง NAS, สวิตช์ และลูกค้าเป็นสาเหตุทั่วไปของการล่มของ อัตราความเร็ว

# ตรวจสอบ MTU บนอินเทอร์เฟซ NAS
ip link show | grep mtu

# ตรวจสอบ MTU บนลูกค้า (Windows)
netsh interface ipv4 show subinterfaces

# ตรวจสอบ MTU บนลูกค้า (Linux / macOS)
ifconfig | grep mtu

ทั้งสามจุดปลายทาง (NAS, สวิตช์, ลูกค้า) ต้อง มี MTU เดียวกัน หากมีอุปกรณ์ใดในเส้นทางมี MTU เล็กกว่า แพ็กเก็ตอาจถูกแบ่งหรือถูกทิ้งอย่างเงียบๆ

ทดสอบอย่างรวดเร็ว: ตั้งค่า MTU เป็น 1500 (มาตรฐาน) ชั่วคราวบนอุปกรณ์ทั้งหมดและทดสอบใหม่ หากความเร็วดีขึ้น ปัญหาอาจเกิดจากการตั้งค่า Jumbo Frame ผิดพลาด
Jumbo Frame (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 cache (ที่เก็บข้อมูลและสแนปช็อต → Cache Acceleration) — cache ที่เสื่อมสภาพสามารถทำให้ I/O ช้าลงได้
ตรวจสอบสุขภาพ S.M.A.R.T. หาก อัตราความเร็ว ของดิสก์ดูผิดปกติ

ขั้นตอนที่ 6: รวบรวมข้อมูลการวินิจฉัยสำหรับการสนับสนุน

หากขั้นตอนข้างต้นไม่แก้ไขปัญหา ให้รวบรวมข้อมูลเหล่านี้และบันทึกบันทึกระบบก่อนเปิดตั๋วสนับสนุน

เปิดตั๋วสนับสนุนที่ https://service.qnap.com/ และแนบผลลัพธ์

คำเตือน

อย่าทำการเปลี่ยนแปลงหลายอย่างพร้อมกัน — เปลี่ยนแปลงทีละตัวแปรและทดสอบใหม่อีกครั้ง
บันทึกการตั้งค่าต้นฉบับก่อนทำการเปลี่ยนแปลง โดยเฉพาะการตั้งค่าเครือข่าย, MTU, การรวม, และการตั้งค่าสวิตช์
การดูผลลัพธ์ของ SMB เพียงอย่างเดียวไม่เพียงพอที่จะระบุสาเหตุที่แท้จริง — หากโปรโตคอลทั้งหมดช้า ให้ทำการแยกชั้นเครือข่ายก่อน
การทดสอบการเขียน dd สร้างไฟล์ชั่วคราวบนวอลุ่ม — ตรวจสอบให้แน่ใจว่ามีพื้นที่ว่างเพียงพอและทำความสะอาดหลังจากนั้น
การปิดใช้งาน SSD cache บนระบบการผลิตอาจลดประสิทธิภาพชั่วคราวสำหรับงานที่พึ่งพามัน หากเป็นไปได้ ให้ทำการทดสอบนี้ในช่วงเวลาบำรุงรักษา
เมื่อเปรียบเทียบ NAS สองเครื่อง ตรวจสอบให้แน่ใจว่า เฟิร์มแวร์ เวอร์ชัน, แอปพลิเคชันที่ติดตั้ง, การตั้งค่า NIC, และการตั้งค่าวอลุ่มเหมือนกันทั้งหมด

อ่านเพิ่มเติม

Was this article helpful?

Yes. No.

50% of people think it helps.

หากต้องการความช่วยเหลือเพิ่มเติม สอบถามผู้ใช้รายอื่นและผู้เชี่ยวชาญของ QNAP ได้ในคอมมูนิตี้ ไปที่ QNAP Community

Please tell us how this article can be improved:

The article is missing important information
The article's solutions do not work
The article is too complicated
The article contains incorrect information
The article is out-of-date

If you want to provide additional feedback, please include it below.