非官方
本頁內容
  1. 01階段 1：記憶體
  2. 02階段 2，步驟 1：核心日誌、SMART 與 HCL
  3. 03階段 2，步驟 2：SMB 或 iSCSI
  4. 04階段 2，步驟 3：DriveTime 中的 Disk Health Scan
  5. 05階段 2，步驟 4：碎片化、飽滿度以及磁碟的能耐
  6. 06階段 3：網路
  7. A基礎知識：NAS 中的磁碟

NAS 效能故障排除：讀寫速度，逐步解說

NAS 上讀寫緩慢有許多可能的原因：記憶體損壞資料或使機器當機、磁碟即將故障、排線或背板不良、通訊協定、磁碟區碎片化或幾乎全滿，或者網路問題。本指南依這個順序，從硬體開始往上逐一檢查，使用的工具是 StorageDiag Workbench & Utilities。

Workbench 有兩個桌面。Utilities 用於安裝它的那台 NAS：DriveTime Analyzer、NetScope、MemHound 與即時日誌。Workbench 用於讀取診斷包：分析該診斷包日誌的核心日誌視窗與 Dr. Trace。在開始功能表 (寫著 Workbench | Utilities 的那一列) 中切換桌面，頁面會重新載入。

  1. 記憶體MemHound，第一優先
  2. 日誌 & SMART連線錯誤、磁碟健康度、HCL
  3. SMB 或 iSCSI單一通訊協定或兩者
  4. 磁碟掃描 & 映射 (map)DriveTime：速度、配置、飽滿度
  5. 網路NetScope 與 iperf3

01階段 1：記憶體

首先排除不穩定的硬體。故障的記憶體模組可能損壞它所承載的資料、造成其他原因都解釋不了的速度下降，或讓整台機器當機。請依照第一篇文章的說明測試 RAM：如何使用 MemHound 正確測試 QNAP 伺服器上的 RAM。MemHound 的 Benchmark and Quality 也會測量記憶體頻寬，並與已安裝模組的 JEDEC 數值比較 (該文章的第 04 節)。NAS 記憶體的特別之處 (混用模組、雙通道、ECC，以及為什麼記憶體看起來還有空閒時仍會出現 OOM 錯誤)，請見該文章的第 05 節：NAS 中的 RAM。

02階段 2，步驟 1：核心日誌、SMART 與 HCL

核心日誌 (kernel log) 與 Dr. Trace

  1. 在 NAS 上切換至 Utilities 並開啟 Kernel Log · LIVE 或 Dr. Trace · LIVE (開始功能表，Live logs)。針對判定結果和日誌分析，即時的 Dr. Trace 視窗會提示您該怎麼做：Run Audit, then switch to the Workbench desk。如果是客戶傳送給您的日誌，請將他們的診斷 ZIP 檔上傳到 Workbench 桌面 (Upload Diagnostic ZIP) 並開啟 Kernel Log (dmesg) 與 Dr. Trace (Diagnosis)。
  2. 在核心日誌中，把搜尋切換成正規表示式 (abc / .*)，再搜尋連線出問題時會出現的記錄行：hard resetting link|10B8B|SError|giving up|link is slow|exception Emask。
  3. 看看 Workbench 在這些行上標了什麼。它會標記 libata 連線重置 (hard resetting link、link is slow)、核心放棄的連接埠 (reset failed, giving up)、SATA PHY 與訊號錯誤 (10B8B、Dispar、PHYRdyChg)、逾時後關閉的 NCQ，以及降速運作的 SATA 連線。
  4. 在 Dr. Trace 中開啟一個事件 (incident)。它會把同一個故障的重複發生 (包括磁碟斷線後又回來) 歸成一個事件，並把可能原因的比重分給磁碟、排線、背板和擴充器 (expander)。
Kernel Log (dmesg)，客戶的診斷包。連接埠 ata6 記錄了 SError: { RecovComm PHYRdyChg 10B8B Dispar }，標記為 Backplane Communication Error 與 SATA 10B8B Signal Error，接著是 hard resetting link。在較下方處，ata10 以 reset failed, giving up 結束：核心捨棄了該連接埠。機器名稱和序號已用點遮蔽。
Dr. Trace，相同的診斷包。Drive 12 路徑上的訊號完整性故障 (signal-integrity fault)，在 229 天內發生 402 次並保留為單一事件。可能原因：背板與內建 SATA 控制器佔 59%，排線 35%，磁碟 6%，並列出判定依據的日誌行。
影片 · 0:49。 在診斷包的核心日誌中搜尋 libata 錯誤，接著看 Dr. Trace 和它的訊號完整性事件 Kernel Log (dmesg) · Dr. Trace · 客戶的診斷包，名稱和序號已遮蔽

SMART、HCL 與磁碟等級 (drive class)

  1. 在 NAS 上開啟 DriveTime Analyzer (Utilities)。Health 分頁會保存每部磁碟每小時的 SMART/FARM 歷史，並轉成 critical、warning 和 info 判定；左側的磁碟清單會用一個圓點標示每部磁碟。
  2. 選一部磁碟，按 View SMART。SMART 視窗會列出每個屬性 (Current、Worst、Threshold、Raw value) 以及針對整部磁碟的判定結果：OK、WARNING 或 CRITICAL。
  3. 看看磁碟卡片上的兩個小標籤。HCL 標籤會比對這部磁碟與 QNAP 針對此 NAS 型號的相容性清單：HCL ✓ 代表已列入，HCL ✗ 代表未列入此型號清單，HCL — 代表不在任何 NAS 的清單上。等級標籤會顯示 Desktop (桌上型)、NAS、Enterprise (企業級)、Surveillance (監控)、Archive (歸檔) 或 Blacklist (黑名單)；桌上型磁碟會標記為 Consumer drive — not recommended for 24/7 NAS use (消費級磁碟 — 不建議用於 24/7 NAS 環境)。

磁碟等級不只影響壽命，也影響速度。消費級 SSD 往往只在快取填滿之前寫得快，快取一滿，在持續負載下速度就會大幅下降。在 NAS 上，穩定的讀寫比短暫的爆發速度更重要。

Health：一台有磁碟正在故障的 NAS。bay 14 中的 Seagate 磁碟因有 369 個重新分配的磁區 (reallocated sectors) 而處於 Critical 狀態，且活動清單日復一日地重複顯示 back up and plan replacement。序號已用點遮蔽。
同一部磁碟在 SMART 視窗中的畫面。HCL ✓ 與 Enterprise：此 NAS 適合的磁碟，但仍然是 CRITICAL，其 Reallocated_Sector_Ct 值為 369。
影片 · 0:45。 DriveTime Health 分頁上的故障磁碟，接著是它在 SMART 視窗中的卡片：HCL、磁碟等級、CRITICAL DriveTime Health · SMART 視窗 · 序號已遮蔽

當日誌顯示連線錯誤或 SMART 顯示警告時，處理磁碟是第一要務：檢查它們是否在 HCL 上、是否為 NAS 或企業級磁碟，以及它們是否健康。磁碟在完全故障前可能會悄悄地損壞資料，因此不要等到它掉線才處理。

03階段 2，步驟 2：SMB 或 iSCSI

在排除硬體因素後，找出速度變慢是否源於單一通訊協定。它只發生在 SMB、只發生在 iSCSI，還是兩者皆有？如果某個用戶端只能使用 iSCSI，這並不能成為跳過檢查的理由：請同時從另一個用戶端透過 SMB 進行測試，以縮小搜尋範圍。

  1. 僅限 iSCSI，使用 Windows Server 用戶端：使用下方命令關閉該 Windows 主機上的 ODX (Offloaded Data Transfer)，重新啟動並再次測試。這是最快的檢查方式，而且不需要任何分析。當診斷包顯示 iSCSI 目標指令中止 (target command aborts) 時，Workbench 也會給出相同的建議。
  2. 兩者皆有：原因在通訊協定之下。繼續檢查磁碟。
# 以系統管理員身分執行 PowerShell。0 = 啟用 ODX (預設值)，1 = 關閉 ODX
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem -Name FilterSupportedFeaturesMode

# 關閉 ODX，然後重新啟動 Windows
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem -Name FilterSupportedFeaturesMode -Value 1

# 重新開啟它
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem -Name FilterSupportedFeaturesMode -Value 0
影片 · 1:42。 SMB 一直斷線：查看共用資料夾和流量 NetScope 封包 · SMB2

04階段 2，步驟 3：DriveTime 中的 Disk Health Scan

在使用 CrystalDiskMark 等外部效能測試工具之前，請先從 NAS 本身測量磁碟。DriveTime 的 Disk Health Scan 會對磁碟區底下的磁碟施加負載，再拿每部磁碟和其他磁碟比較並評分。

  1. 開啟 DriveTime Analyzer 的 Speed 分頁，並在標題列選擇磁碟區。
  2. 選擇測試。磁碟區測試 (循序與隨機讀寫、50/50 混合，或是包含所有四個階段與 SMART 的 FULL REPORT) 只會將其測試檔案寫入該磁碟區的暫存資料夾中，然後將其刪除。Read-only disk scan 會讀取原始磁碟，先逐一讀取，再全部一起讀取，不寫入任何資料。
  3. 按 ▶ Analyze。掃描會回報每部磁碟的延遲 (中位數、p95、最大值)、使用率、IOPS 和佇列深度，並把它標為 OK、WATCH 或 SUSPECT。
  4. 按 Save report (.md)。報告將以 report-ioutils-storagediag-utilities-<date>-<time>.md 儲存到 Public 共用資料夾，旁邊會有一個 -trace.csv 檔；開始功能表中的 Disk reports 會列出它們。
Speed，執行前。上方為每個裝置的即時 await (等待時間)，下方為 Disk Health Scan 表單，已選取 Read-only disk scan，並在其下方清楚標示所需時間。
影片 · 1:26。 磁碟區寫入了什麼，底下的磁碟實際上又能做到什麼 DriveTime IO Analyzer · 服務已停止

解讀 await

某部磁碟的 await 偏高，本身並不表示它正在故障。Await 是一個請求排隊加上處理所花的時間。負擔陣列 I/O 比其他磁碟多的磁碟，因為做得多，等得也久；所以掃描會改用服務時間 (service time) 評估這種磁碟，並註明這一點。在下方報告中，故障磁碟旁邊那部健康的磁碟，在隨機讀取階段就得到這樣的註記：carries 62% of the array's I/O (1.6× peer IOPS) — its await and queue are load, not a fault。反過來也會發生：await 正常、傳輸率卻遠低於其他磁碟的那部，可能正有不明顯的機械故障。所以唯讀掃描除了全部一起讀，也會逐一單獨讀取每部磁碟。

報告及其判定

報告開頭會有一個讓人一目了然的判定：沒有異常磁碟時顯示 OK，或是 WARNING / CRITICAL，並指出最弱的一環和它表現最差的階段。接著是每部磁碟的表格、執行前後的 SMART 證據、使用的閾值，以及逐秒的追蹤記錄。儲存速度會隨 NAS 上的負載而變動，因此請執行多次掃描以確認異常是否重複出現；每份報告中的追蹤記錄讓您可以逐行比較兩次執行結果。

Reports 視窗中儲存的報告。CRITICAL — Weak link: sdf (slot 14), worst in Sequential read：不穩定的延遲 (p95 是其中位數的 12 倍)、369 個重新分配的磁區，以及執行期間增加的 G-sense 計數。這就是上方 Health 分頁中的那部磁碟。
影片 · 1:55。 一部磁碟拖慢了整個陣列 DriveTime IO Analyzer · 完整報告 · SMART

須知事項。報告為純 Markdown 文字，因此 AI 助理可以直接閱讀：將其貼上並詢問有什麼突出之處，它可能會指出人眼容易忽略的模式。這個檔案正是 QNAP 支援團隊需要的：從 Reports 視窗下載它，並與包含 SMART 讀數和核心日誌的 NAS 診斷 ZIP 檔一起附加至支援工單中。對於日誌本身，Workbench 擁有自己的 AI 日誌分析功能 (Kernel Log 與 Dr. Trace 中的 ✨ 按鈕)，它會將由日誌建立的提示 (prompt) 傳送給 OpenAI、Claude 或 Gemini，這需要管理員儲存在 Settings 中的 API 金鑰。

05階段 2，步驟 4：碎片化、飽滿度以及磁碟的能耐

硬碟規格表上的數字，在日常使用中很少能達到。

  1. 碎片化 (Fragmentation)。DriveTime 的 Disk Map 標籤頁會顯示磁碟區或共用資料夾中的檔案是如何配置的，以及它們底下的可用空間破碎程度。在標題列選擇磁碟區，再按 Scan：Sample (樣本) 會在您設定的時間限制內進行讀取，Full (完整) 則會讀取整個目錄樹 (tree)。Fragmented files 分數解讀如下：0–30 為沒有碎片化問題，31–55 為稍微碎片化，56 及以上為嚴重碎片化。掃描僅會進行讀取；它絕不會移動任何區塊。
  2. 飽滿度 (Fullness)。保持磁碟區 (包含即時資料與快照) 的使用率在 80% 以下。當磁碟區超過 80% 時，Capacity 視窗會發出警告。在 QuTS hero 上，Disk Map 會在儲存池 (pool) 長條圖上標示 80% 和 90%：當超過大約 80% 時，ZFS 在放置每次寫入時會更加吃力，並且儲存池上所有共用資料夾的寫入速度都會變慢。
  3. 不要進行磁碟重組。 在含有快照 (snapshots) 的磁碟區上，重組工具每移動一個區塊，都會再次消耗儲存池的空間，直到保留舊區塊的快照過期為止，因此快照會隨著移動的資料量而增大。考量到所花費的時間和對磁碟的磨損，這並不值得。因此，Workbench 沒有提供重組按鈕，保持磁碟區使用率在 80% 以下才是解決之道。
  4. 磁碟的能耐。目前最快的硬碟在最外圈磁軌的額定速度約為 280 MB/s。在內圈磁軌或碎片化的磁碟區上，速度降至三分之一是很常見的；如果在讀寫混合的情況下，每顆磁碟 100 到 120 MB/s 是實際日常使用的合理數據。磁碟區的速度取決於 RAID 級別、磁碟的飽滿度和碎片化程度，以及由此造成的磁頭移動。

Disk Map 只顯示配置狀態。要確認磁碟能否跟上工作負載，請在工作負載執行時觀察 Speed 分頁，並在 Health 分頁查看每部磁碟的歷史記錄。

95% 滿的磁碟區 Disk Map，單一硬碟，60 秒的掃描樣本。大部分的方塊已完全配置 (fully allocated)；剩餘的可用空間多半是小區塊 (紅色) 或破碎的 (琥珀色)，只有少數幾處較長的連續空間 (綠色)。這張圖省略了檔案清單。
影片 · 0:35。 這個磁碟區上的檔案到底有多零碎？ DriveTime Fragviewer · 可用空間對應圖 · ext4 & ZFS

06階段 3：網路

如果磁碟證實健康而且夠快，瓶頸可能在網路。NetScope 用 iperf3 測量連線速度。

  1. 開啟 NetScope (Utilities) 的 Bandwidth 分頁，然後按 Server。選擇網路介面。iperf3 監聽器會自動啟動 (連接埠 5201)，關閉視窗時就會停止。
  2. 在執行 Workbench & Utilities 的第二台 NAS 上，開啟 NetScope 的 Bandwidth，按 Client，選擇這台 NAS (或在 Manual 下方輸入它的 IP)，再按 Start Test。若從 Windows PC 測試，請使用 Windows 版的 NetScope 用戶端：NetScope-latest.exe，連結位於 NetScope 的標題列。
  3. 如果測試顯示頻寬太低，就別再查 NAS 的儲存空間，改查網路：交換器、網路線、網路卡和路由設定。
NetScope，Bandwidth，伺服器 (Server)。 監聽器會在所有介面的連接埠 5201 上等待，直到視窗關閉。測試用 NAS 的位址已用點遮蔽。
影片 · 0:28。 問題出在網路還是 NAS？點選兩次就能執行 iperf NetScope · NetScope Windows

A基礎知識：NAS 中的磁碟

並非每種磁碟都適合用在 NAS。磁碟的等級決定它能和 RAID 陣列好好配合，還是會拖垮陣列；它的 SMART 屬性則會告訴您它還能用多久。

為何桌上型 (desktop) 磁碟不適合 RAID

桌上型磁碟沒有 TLER/ERC。當它遇到難以讀取的區塊時，它會不斷嘗試恢復資料長達數分鐘，而 RAID 控制器通常只會等待大約 7 秒鐘。之後，控制器會將這顆其實健康的磁碟視為故障並將其踢出陣列：這會造成不必要的降級和高風險的重建。此外，桌上型磁碟沒有 24/7 全天候運作的評級、沒有振動感測器 (RV)，年度工作負載也低了好幾倍。

SMR 與 CMR：為何它對 RAID 很重要

CMR 把磁軌並排寫入：寫入快速而且可預測，這正是重建所需要的。SMR 像屋瓦一樣讓磁軌互相重疊，因此每次覆寫都要重寫一整個區域 (zone)。在重建過程的持續寫入下，磁碟快取會被填滿，磁碟停頓數秒並超過控制器的逾時時間，然後控制器就會判定該磁碟已經死亡，導致重建時間從數小時拉長到數天。對於 RAID 和 NAS，請務必只使用 CMR 磁碟。

磁碟等級 (Disk classes)
等級適用於轉速 (RPM)年度工作負載RV 感測器TLER磁碟槽 (Bays)適用於 NAS
NAS家庭與辦公室 NAS，24/7，輕至中度負載5400~180 TB數量有限有最多 8 個是
NAS Pro多槽位 NAS、虛擬化、資料庫7200~300 TB有有最多 24 個是
Enterprise伺服器機房、24 槽以上的陣列、極端負載7200~550 TB多軸有無限制是
Surveillance (監控)錄影機與 CCTV：多個串流的循序寫入5400/7200~180–550 TB部分型號有NVR適用於攝影機
Archive (SMR)冷資料、偶爾的循序寫入5400低無無—僅限備份
Desktop (桌上型)單一 PC，每天使用數小時5400/7200~55 TB無無1否
SMART 屬性：Workbench 中的 DriveTime 如何為它們評分
ID屬性涵義警告 / 危急應對措施
5Reallocated_Sector_Ct壞軌已移至備用區域；磁碟逐漸故障時，數值會持續增加≥ 1 / ≥ 50進行備份；在 RAID 中，重建可能會失敗
197Current_Pending_Sector等待重新分配的不穩定磁區≥ 1 / ≥ 5進行備份，更換磁碟；通常會與 5 和 198 一起增加
198Offline_Uncorrectable無法讀取的磁區，已無法恢復≥ 1 / ≥ 1立即備份，更換磁碟
187Reported_Uncorrect磁碟 ECC 無法修正的錯誤≥ 1 / ≥ 10強烈的故障前兆，更換磁碟
196Reallocation_Event_Count磁碟移動磁區的次數≥ 1 / ≥ 20與 5 一起觀察
10Spin_Retry_Count磁碟在第一次嘗試時未能啟動旋轉 (馬達、機械裝置)≥ 1 / ≥ 10瀕臨卡死，更換磁碟
188Command_Timeout指令超過時間限制，磁碟無回應≥ 1 / ≥ 100檢查排線和電源；如果數值持續增加則更換
199UDMA_CRC_Error_CountSATA 傳輸錯誤：通常是排線或背板的問題，而非磁碟≥ 1 / ≥ 100重新插拔磁碟，更換排線；重要的是看它是否持續增加
194Temperature_Celsius磁碟的溫度≥ 55 °C / ≥ 65 °C改善散熱和磁碟間距
NVMePercentage Used已使用的額定耐用度比例≥ 80 % / ≥ 100 %達到 80 % 時請計畫更換
NVMeMedia and Data Integrity Errors無法復原的 NAND 媒體錯誤≥ 1 / ≥ 10進行備份，更換磁碟
NVMeCritical Warning警報位元：備用空間、溫度、唯讀模式任何一個位元每一個被設定的位元都代表嚴重問題

在 RAID 陣列中，屬性 5、197 和 198 不單只是一顆磁碟的風險：重建會增加負載，可能讓第二顆較弱的磁碟也故障，這時重建就會失敗，整個儲存池都會遺失。請及早處理。在 Seagate 磁碟上，屬性 1、7 和 195 顯示的 RAW 值高達數百萬是正常的；請拿 VALUE 和 WORST 與 THRESH 比較，不要看 RAW。

SSD 快取與不斷電系統 (UPS)
模式系統作用UPS
Read-only (唯讀)QTS將頻繁讀取的資料複製到 SSD；原始檔案仍保留在磁碟上建議使用
Read cache (L2ARC)QuTS hero將 SSD 作為第二層讀取快取建議使用
Write-only / read-write (唯寫 / 讀寫)QTS寫入的資料會先存到 SSD，稍後才寫到磁碟不可或缺
ZIL (SLOG)QuTS hero在 SSD 上的同步寫入日誌；一律為鏡像不可或缺

經驗法則。 如果有任何寫入在到達磁碟前先在緩衝區中等待 (回寫式 / write-back、SLOG、沒有斷電保護 / PLP 的磁碟快取)，那麼 UPS 是不可或缺的。如果快取僅提供讀取服務，則建議使用 UPS。寫入快取必須建立在有保護的陣列類型上 (RAID 1、5、6 或 10)，絕對不要建在 Single、JBOD 或 RAID 0 上。

記憶體 (雙通道、ECC、混用模組、症狀與 OOM 錯誤) 在 RAM 指南中有獨立的一節說明：NAS 中的 RAM。