NVMe 對 VPS 重要嗎？與 SATA SSD 比較

NVMe 對 VPS 重要嗎？

當軟體發出大量小型讀寫要求，並等待每一項操作完成時，NVMe 對 VPS 很重要。對於提供快取頁面的網站，或大部分時間都在等待網路的程式，NVMe 幾乎沒有影響。儲存媒體只是其中一項因素。磁碟前方的 hypervisor，以及共用同一部主機的其他客體，會決定您實際可獲得的效能上限。

NVMe 的變更內容與未變更內容

NVMe (non-volatile memory express) 不是一種 flash memory，而是存取 flash 所使用的通訊協定與連線。NVMe 裝置連接至 PCIe (peripheral component interconnect express) 通道，並使用 NVMe 通訊。SATA (serial ATA) SSD 則連接至 SATA link，並使用 AHCI (advanced host controller interface) 通訊。兩者儲存位元組的 memory chips 可能完全相同。

兩者有兩項差異，且差異都在於 command path，而非儲存媒體本身。

Queues。 AHCI 提供 kernel 一個可容納 32 個命令的 command queue。NVMe 支援數千個 queues，實務上通常每個 CPU core 一個，而且每個 queue 的深度都遠超過 32。單一 process 一次讀取一個 block 時，無法感受到這項差異。具有 64 個待處理讀取要求的 database 則可以：在 SATA 上，第 33 個要求必須等待 queue slot，裝置甚至尚未看見該要求；NVMe 裝置則會全部接受，並同時處理。

Link width。 SATA III link 的速度為 6 Gbit/s，扣除 protocol overhead 後，實際資料傳輸量約為 550 MB/s。無論後方使用何種 flash，這都是固定上限。4 條 PCIe lanes 每秒可傳輸數 GB，因此 link 不再是限制。

Latency 通常是最容易產生錯誤預期的部分。在 queue depth 1，也就是同一時間只有一個要求處於處理中時，SATA SSD 回應 4k read 約需 100 到 150 microseconds。NVMe 約需 80 到 100 microseconds。兩者都很快，單一要求的差異不會被你執行的任何工作察覺。差異會在 concurrency 下擴大。Queue depth，也就是同一時間處理中的要求數量，是決定這兩種媒體表現相近或差異顯著的設定。

Network block storage 是具有不同物理特性的第三類儲存。寫入資料會經過 network 傳送至 storage cluster，只有在 cluster 保存資料後才會確認完成，因此其 latency 以 milliseconds 而非 microseconds 計算。換取這項 latency 的是 durability：volume 的存續時間會超過其連接的 host，且可以建立 snapshot 並調整大小。

常見公開數據：NVMe、SATA SSD 與網路儲存

[
  {
    "disk": "Local NVMe SSD",
    "iops_4k_read": "184,000",
    "p99_latency_ms": 0.4,
    "seq_read_mbps": "3,400"
  },
  {
    "disk": "Local SATA SSD",
    "iops_4k_read": "90,000",
    "p99_latency_ms": 1.2,
    "seq_read_mbps": "550"
  },
  {
    "disk": "Network block storage",
    "iops_4k_read": "12,500",
    "p99_latency_ms": 6.5,
    "seq_read_mbps": "250"
  }
]

本機 NVMe 裝置在佇列深度 32 下，通常標示為 184,000 次隨機 4k 讀取 IOPS（每秒輸入／輸出作業數）。SATA SSD 的相同測試結果通常接近 90,000，效能受單一 AHCI 佇列與 6 Gbit/s 連線限制。網路區塊儲存通常受供應商限制，而非硬體限制；12,500 是常見的文件化上限。

延遲會以使用者實際感受到的單位呈現相同差異。p99 讀取延遲表示最慢的 1% 請求，在本機 NVMe 上約為 0.4 ms，在 SATA 上約為 1.2 ms。若在路徑中加入網路，延遲會變為 6.5 ms，超過 NVMe 數據的 10 倍。

循序讀取的差距最大，但參考價值最低：3,400 MB/s，相較於 550 MB/s。伺服器上幾乎沒有工作會以全速從頭到尾讀取單一大型檔案。隨機讀取與延遲數據，才更能說明資料庫、郵件佇列或套件管理程式的實際行為。

哪些工作負載會察覺磁碟

以下規則可以解釋所有情況：只有在等待磁碟時，工作負載才會察覺磁碟。Linux 會將最近使用的檔案資料保存在 RAM 的 page cache 中，因此檔案的第 2 次讀取不會到達儲存裝置。如果工作集，也就是實際使用中的資料，能夠容納在 RAM 中，則第 1 次讀取後，後續讀取都會變成記憶體讀取。寫入則不同。應用程式使用 fsync() flush 的任何寫入，都必須先寫入穩定儲存裝置，應用程式才能繼續執行。

會執行提交的工作。 PostgreSQL、MySQL 和 SQLite 會在提交時呼叫 fsync() 或 fdatasync()，而每次提交都會等待裝置回應。因此，單一連線的提交速率取決於寫入延遲，而不是頻寬。flush 時間為 0.2 ms 的裝置，每秒可完成的提交數量遠高於需要 5 ms 的裝置；再高的處理量也無法改變這一點。當 flush 速度跟不上時，MySQL 會在錯誤日誌中記錄此情況：

[Note] InnoDB: page_cleaner: 1000ms intended loop took 4589ms. The settings might not be optimal.

PostgreSQL 會在 checkpoint 訊息中回報此情況。較大的 sync= 值表示 flush 本身速度較慢：

LOG:  checkpoint complete: wrote 8192 buffers (25.0%); write=27.694 s, sync=11.207 s, total=39.001 s

會處理大量小型檔案的工作。 每個檔案都涉及中繼資料作業，而單次大型循序讀取不需要這些作業。npm install、大型儲存庫的 git clone、解開容器映像檔、Maildir 郵件儲存區，以及巡覽大型樹狀目錄的備份，都會將時間耗費在小型隨機存取上。VPS 上的 restic 備份工作會讀取並雜湊所有先前未處理過的檔案，因此，包含 1000000 個檔案的備份，其實際耗時會密切受到隨機讀取延遲影響。du -sh 也是如此，因為它只讀取中繼資料。

超出 RAM 容量的資料庫也屬於此類。一旦索引無法再容納於 page cache 中，每次查詢都會變成隨機讀取，磁碟便重新進入關鍵路徑。

哪些工作負載不會受到磁碟影響

部落格或小型公司網站。 頁面很小。第一次請求後，頁面快取即可容納所有頁面。限制因素是頁面呈現所需的 CPU 或資源的頻寬。使用 Ubuntu 24.04 上的 LAMP 堆疊提供低流量網站時，系統暖機後幾乎不會執行磁碟 IO。

媒體串流。 單一 4K 串流以 40 Mbit/s 的速率讀取 5 MB/s。10 個串流會讀取 50 MB/s，即使是網路區塊儲存也能輕鬆提供。在 VPS 上執行 Jellyfin 媒體伺服器時，限制因素是網路對外傳輸額度，以及進行轉碼時的 CPU，而不是儲存媒體。

本機模型推論。 在 VPS 上執行 Ollama 以自行託管 LLM時，系統只會讀取模型檔案一次，之後在 RAM 中運作。NVMe 可將載入 20 GB 模型的時間從數分鐘縮短至數秒。但這不會改變每秒處理的 token 數量，因為該數量受記憶體頻寬和 CPU 限制。

任何等待外部服務的工作。 如果工作程式每項工作有 800 ms 用於 HTTP 請求，換用更快的磁碟也不會提高速度。

虛擬機器管理程式的重要性不亞於儲存媒體

您實際上不會直接與裝置通訊，而是與虛擬機器管理程式所呈現的虛擬磁碟通訊。這通常透過 virtio 實現，而這一層的數項設定，重要性往往高於 NVMe 與 SATA 之間的差異。

您無法從客體系統內部查看儲存媒體。 lsblk -d -o NAME,ROTA,SIZE,MODEL 會顯示 vda，但 model 欄位為空，因為 virtio 不會傳遞磁碟識別資訊。cat /sys/block/vda/queue/rotational 回報的是虛擬機器管理程式所宣告的資訊，因此其中的 0 並不能證明儲存媒體是 flash。來自 nvme-cli 套件的 nvme list，在大多數 VPS 上不會列出任何裝置，即使主機裝滿 NVMe 磁碟也是如此，因為您的磁碟是 virtio 裝置，不是 NVMe 裝置。標示為 NVMe 的方案，通常是在說明主機使用的儲存媒體。您的 volume 仍可能透過網路連接。

主機的快取模式對數據的影響大於儲存媒體。 如果主機啟用 writeback caching，客體系統中的 fsync() 可能在主機將資料寫入自身 RAM 後立即返回。這會產生任何實體裝置都無法達到的基準測試結果。這也表示主機故障時，資料庫認為已安全寫入的資料可能遺失。使用 none 快取模式時，數據較低，但較為真實。

上限與突發額度。 許多供應商會限制每個 volume 或方案的 IOPS，許多網路 volume 也會使用突發額度。突發額度是一組點數：在點數用盡前，volume 可以維持高速運作；之後便會降至低得多的基準速率。這種情況很容易辨識。匯入或還原作業會快速執行數分鐘，接著突然大幅變慢，並持續維持低速，而您的設定沒有任何變更。這表示突發額度已用盡。

鄰近租戶。 在共用主機上，其他客體系統的活動會影響您磁碟的延遲。因此必須進行多次測量。早上執行相同測試，晚上再執行一次，然後比較結果差異。在繁忙的主機上，同一個 volume 兩次執行結果的差異，往往大於已發布的兩種儲存媒體之間的差異。

如何測量 VPS 實際擁有的磁碟效能

安裝標準 IO 基準測試工具 fio，然後進行測量。先注意三點。測試會建立檔案，因此會使用磁碟空間，也會計入帳單中的 IOPS 配額。測試時間應保持簡短。不要對正在提供即時流量的磁碟區，以完整佇列深度執行測試，否則會與自己的應用程式競爭資源。

sudo apt update && sudo apt install -y fio ioping sysstat
cd /var/tmp

佇列深度為 32 的隨機讀取，這是供應商通常標示的深度：

fio --name=randread --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
  --runtime=30 --time_based --group_reporting

重要的行從 read: 開始：

  read: IOPS=184k, BW=719MiB/s (754MB/s)(21.1GiB/30001msec)

--direct=1 會繞過客體頁面快取，因此結果反映的是裝置，而不是 RAM。省略此選項會測量記憶體，得到磁碟無法達到的數值。如果空間足夠，請使用 --size=4G 或更大的檔案，因為 1G 檔案可能完全位於主機的快取中，使結果顯得過高。

佇列深度 1 可顯示原始延遲，也就是單執行緒程序實際感受到的延遲：

fio --name=lat --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based

提交測試可預測資料庫行為。它會寫入 4k，並在每次寫入後呼叫 fdatasync()，因此報告的速率包含 flush 所需的時間：

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

該測試的 IOPS 數值接近單一資料庫連線每秒可提交的小型交易數上限，因為提交作業會等待相同的 flush。

若要不使用 fio 快速取樣：

ioping -c 20 .

--- . (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.13 ms, 76 KiB read, 4.60 k iops, 17.9 MiB/s
min/avg/max/mdev = 174.2 us / 217.6 us / 386.1 us / 51.3 us

mdev 數值表示平均偏差，其重要性不亞於平均值。閒置伺服器上的偏差很大，表示儲存後端由多個使用者共用，且目前負載很高。

如何讀取結果

截至 2026 年 7 月，以下是小型 VPS 的合理判讀方式。在佇列深度 32 下，每秒數萬次 4k 隨機讀取 IOPS，且佇列深度 1 的延遲低於約 0.3 ms，通常表示使用本機快閃儲存。佇列深度 1 的延遲達數毫秒，表示存在網路路徑，無論方案名稱為何。循序讀取速度若在接近 550 MB/s 時停止，通常是 SATA 連結的特徵。若數值遠高於任何單一裝置的能力，表示路徑中有快取，幾乎總是在主機端。

若要查看目前的工作負載如何影響磁碟：

iostat -x 1 3
vmstat 1 5
cat /proc/pressure/io

在 iostat -x 的輸出中，查看 r_await 和 w_await，這兩者分別是要求等待的平均毫秒數，以及 aqu-sz，即平均佇列長度。虛擬磁碟上的 %util 可忽略。它顯示至少有一個要求待處理的時間比例；對於可同時處理許多要求的裝置而言，這無法表示裝置是否飽和。因此，%util 為 100 且 r_await 為 0.2 ms，代表磁碟正忙碌但狀態正常。在 vmstat 中，wa 欄位是 CPU 時間中等待 IO 的百分比。若核心提供 /proc/pressure/io，其 some avg10= 值表示最近 10 秒內至少有一個工作因等待 IO 而停滯的時間比例。這是判斷儲存裝置是否為瓶頸最直接的依據。

磁碟受限的 VPS 外觀

高負載平均值、閒置的 CPU，以及 vmstat 中較大的 wa，表示處理程序正在等待磁碟。最明確的核心訊號是 dmesg -T 中的這則訊息：

INFO: task jbd2/vda1-8:194 blocked for more than 120 seconds.

這行訊息會出現，是因為核心執行緒等待儲存裝置回應超過 2 分鐘，因此 hung task watchdog 記錄了這個事件。jbd2 是 ext4 日誌執行緒，表示整個檔案系統都在等待，而不是某個行為異常的程式。在 VPS 上，這通常表示儲存後端有問題，或 IOPS 配額已耗盡。

應用程式的症狀也呈現相同模式。回應時間中位數仍可接受，但最慢的要求形成較長的尾端，因為只有觸及磁碟的要求會受到影響。apt upgrade 會在 Unpacking 停留數分鐘，因為 dpkg 寫入時會執行 flush。大型儲存庫中的 git status 需要數秒。這些是中繼資料和 flush 的成本，因此增加頻寬並無法改善情況。

磁碟成為限制時的處理方式

先購買 RAM，再購買 IOPS。 如果工作集能容納在頁面快取中，讀取根本不會到達磁碟。將記憶體加倍通常比改用更快的儲存類別更有效，而且通常成本更低。

在資料允許的情況下，減少 flush 次數。 在 PostgreSQL 中，synchronous_commit = off 可讓提交在資料寫入磁碟前返回。如果伺服器故障，您可能會遺失最後幾分之一秒內的交易。資料庫不會損毀，因為預寫式記錄仍會依序寫入。這項取捨適合分析用副本，但不適合付款系統。MySQL 中的 innodb_flush_log_at_trx_commit = 2 也是相同的取捨。

將小型檔案批次處理。 傳輸或備份 1000000 個小型檔案時，主要成本來自每個檔案的個別處理成本。因此，在高延遲儲存裝置上，先建立封存檔，再傳輸單一資料流，會比逐一複製整個檔案樹更快。

讓 thin volume 上的 discard 維持運作。 在 thin provisioned storage 上，後端必須等檔案系統告知某個區塊已釋出，才知道該區塊可用。如果 volume 從未執行 trim，寫入效能會逐漸下降。Ubuntu 會提供每週執行的 timer：

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av 會列印每個掛載點所 trim 的位元組數。若訊息表示不支援 discard 操作，代表虛擬磁碟未將 discard 傳遞至主機，因此不需要修正任何設定。

略過 IO scheduler 調校。 在 virtio 磁碟上，cat /sys/block/vda/queue/scheduler 通常已顯示 none，而實際的排程會在您無法存取的主機上進行。同樣略過 noatime：Ubuntu 預設會以 relatime 掛載，這已經避免幾乎所有 atime 寫入。

選擇方案

如果伺服器上執行資料庫、郵件伺服器、CI runner 或大量套件的建置工作，請選擇 NVMe。對於有快取的網站，或主要耗時在外部呼叫的應用程式，不必支付額外費用。如果不確定，磁碟可能不是限制因素，因為大多數小型 VPS 工作負載通常會先耗盡 RAM 或頻寬。

從第一天開始測量，並在執行新 VPS 上的前十分鐘時，將輸出保存在檔案中。基準資料可讓你日後證明主機變慢，而不是程式碼造成問題。優先選擇會以書面說明儲存裝置類型及任何 IOPS 上限的供應商。如果方案標示為 NVMe，但佇列深度為 1 的讀取需要 4 ms，表示你使用的是配置 NVMe 主機上的網路儲存。這是合理的銷售方式，但你購買的是另一種產品。

FAQ

NVMe 是否一定比 VPS 上的 SATA SSD 更快？

不一定。在佇列深度為 1 時，兩者的效能接近；4k 讀取延遲約為 80 到 150 微秒，單執行緒程式無法分辨兩者差異。當同時有許多要求等待處理時，NVMe 會開始領先，因為 AHCI 只有一個可容納 32 個命令的佇列，而 NVMe 提供數千個更深的佇列。在共用主機上，其他 guest 的負載可能比儲存媒體本身更大幅度地改變延遲。因此，請使用 fio 測量自己的儲存區，不要只看方案名稱。

如何確認 VPS 實際使用的是 NVMe？

你無法直接確認，因為 virtio 會隱藏實體裝置。lsblk 會顯示 vda，但不提供型號字串；nvme list 不會傳回任何內容；/sys/block/vda/queue/rotational 只會回報 hypervisor 宣告的資訊。請改為測量實際效能。佇列深度為 1 的隨機 4k 讀取若低於約 0.3 ms，表示使用本機 flash。若延遲為數毫秒，表示路徑中存在網路躍點。循序讀取速度若接近 550 MB/s 後停止，表示使用 SATA 連線。

NVMe 會讓我的網站載入更快嗎？

通常不會。第一次要求之後，Linux 會從 RAM 中的頁面快取提供檔案，因此磁碟會停止活動。小型 VPS 的頁面速度通常受應用程式 CPU 執行時間和頻寬限制。如果網站每次要求都會寫入資料，磁碟就會重新進入關鍵路徑。例如，使用資料庫的購物車頻繁執行 commit 時，每次 commit 都必須等待 flush 完成。

VPS 的 fio 結果達到多少才算良好？

截至 July 2026，使用本機 flash 的小型 VPS 通常可在佇列深度 32 下，對 4k 隨機讀取提供每秒數萬 IOPS；佇列深度 1 的延遲則低於 0.3 ms。網路區塊儲存通常提供每秒數千 IOPS，延遲為數毫秒。請在不同時段執行測試 3 次。各次測試結果差異很大時，比平均值更能說明問題，因為這表示主機上的其他 guest 對你的效能造成了多大影響。

我應該將資料庫放在網路區塊儲存上嗎？

可以，許多代管服務也採用這種方式，但 commit 路徑會因此付出代價。每次 flush 都必須經過網路，因此單一連線每秒可執行的小型交易數量，會少於使用本機 flash 時的數量。相對地，你可獲得即使主機故障仍能保留的持久性。如果你為高寫入量資料庫選擇網路儲存，請將工作合併為較大的交易，讓較少的 flush 能夠處理更多資料列。