NVMe 與 SSD VPS 有差嗎？效能比較與實測方法

VPS 上的 NVMe 重要嗎？

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

NVMe 的變更內容，以及不會變更的部分

NVMe（non-volatile memory express）不是一種 flash memory，而是存取 flash 所使用的通訊協定與連線介面。NVMe 裝置連接在 PCIe（peripheral component interconnect express）通道上，並使用 NVMe 通訊。SATA（serial ATA）SSD 則連接在 SATA 介面上，並使用 AHCI（advanced host controller interface）。兩者儲存資料的記憶體晶片可能完全相同。

兩者有 2 項差異，而且都與命令路徑有關，不是儲存媒體本身不同。

佇列。 AHCI 提供核心 1 個可容納 32 個命令的命令佇列。NVMe 可提供數千個佇列，實務上通常每個 CPU 核心 1 個，而且每個佇列的深度都遠超過 32。單一程序每次只讀取 1 個區塊時，無法感受到這項差異。具有 64 個未完成讀取要求的資料庫則可以感受到：在 SATA 上，第 33 個要求必須等待佇列空出位置，裝置甚至還沒看見它；NVMe 裝置則可全部接受，並同時處理。

連線寬度。 SATA III 連線的速度為 6 Gbit/s，扣除通訊協定額外負荷後，實際資料傳輸量約為 550 MB/s。無論後方使用哪種 flash，這都是固定上限。4 條 PCIe 通道可傳輸每秒數 GB 的資料，因此連線不再是瓶頸。

延遲通常是預期最容易出錯的部分。在 queue depth 為 1，也就是同一時間只有 1 個要求處於傳輸中的情況下，SATA SSD 完成 1 次 4k 讀取約需 100 到 150 微秒。NVMe 約需 80 到 100 微秒。兩者都很快，對單一要求而言，實際執行的程式不會注意到差異。差距會在並行處理時擴大。Queue depth，也就是同時處於傳輸中的要求數量，決定這兩種媒體看起來相近，還是差異明顯。

網路區塊儲存是第 3 種類型，其運作特性不同。寫入作業會經由網路傳送至儲存叢集，只有叢集保存資料後才會回應確認，因此延遲是以毫秒而非微秒計算。換取這項延遲成本的是持久性：即使連接該磁碟區的主機失效，磁碟區仍會保留，而且可以建立 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 中，因此第二次讀取檔案時不會再存取儲存裝置。若工作集，也就是實際使用中的資料，能容納在 RAM 內，第一次讀取後，後續讀取就會變成記憶體讀取。寫入則不同。應用程式以 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、大型 repository 的 git clone、解開 container image、Maildir 郵件儲存區，以及遍歷大型目錄樹的備份，都會將時間耗費在小型隨機存取上。VPS 上的 restic 備份工作 會讀取並計算所有先前未處理檔案的雜湊，因此，包含 1000000 個檔案的備份，其實際耗時會密切反映隨機讀取延遲。du -sh 也是如此；它只讀取中繼資料，不讀取其他內容。

超出 RAM 容量的資料庫也屬於這類工作。索引不再能容納於 page cache 後，每次查詢都會變成隨機讀取，磁碟也會重新回到關鍵路徑上。

哪些工作負載不會感受到磁碟差異

部落格或小型企業網站。 頁面檔案很小，第一次請求後就會全部留在頁面快取中；限制因素是頁面產生所需的 CPU 或素材傳輸頻寬。使用 Ubuntu 24.04 上的 LAMP stack 提供低流量網站時，快取暖機後幾乎不會產生磁碟 IO。

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

本機模型推論。 在 VPS 上執行 Ollama 以自行代管 LLM 時，只會讀取一次模型檔案，之後就在 RAM 中執行。NVMe 可將 20 GB 模型的載入時間從數分鐘縮短至數秒，但不會改變每秒 token 數；該數值取決於記憶體頻寬與 CPU。

任何等待外部服務的工作負載。 如果某個 worker 每個工作有 800 ms 用於 HTTP 請求，換用更快的磁碟也不會加快執行速度。

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

您實際上不會直接存取裝置，而是存取虛擬機器管理程式提供的虛擬磁碟，通常透過 virtio 提供。這一層的多項設定，往往比 NVMe 與 SATA 的差異更重要。

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

主機快取模式對數據的影響大於儲存媒體。 如果主機啟用 writeback caching，guest 的 fsync() 可能在主機將資料寫入自身 RAM 後立即返回。這會產生任何實體裝置都無法達到的 benchmark 結果，也表示主機當機時，可能遺失資料庫認為已安全寫入的資料。使用 none 快取模式時，數據較低，但更接近實際情況。

上限與 burst credits。 許多 provider 會依 volume 或方案限制 IOPS，許多 network volume 也使用 burst allowance。burst allowance 是一組 credits。volume 會在 credits 用完前維持高速，之後降至低得多的 baseline。這種情況很容易辨認。import 或 restore 開始時會快速執行數分鐘，之後突然大幅變慢，並持續維持低速，而您的設定沒有任何變更。這表示 credits 已用完。

鄰近租戶。 在 shared host 上，其他 guest 的活動會影響您磁碟的延遲。因此需要重複測量，而不是只測量一次。早上執行相同測試，晚上再執行一次，然後比較兩次結果的差異。在繁忙的主機上，同一個 volume 兩次測試的差異，往往大於已發布的兩種儲存媒體之間的差異。

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

安裝標準 IO 基準測試工具 fio，然後進行測量。先注意三點。測試會建立檔案，因此會使用磁碟空間，也會計入計費的 IOPS 額度。每次執行時間應保持短暫。不要在正在提供即時流量的 volume 上，以完整 queue depth 執行測試，否則會與自己的應用程式競爭 I/O 資源。

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

以下是 queue depth 為 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 會繞過 guest page cache，因此結果反映的是裝置，而不是 RAM。省略此參數時，測量到的是記憶體效能，所得數值可能高於任何磁碟可達的效能。如果空間足夠，請使用 --size=4G 或更大的檔案，因為 1G 檔案可能完全位於主機的 cache 中，導致結果過於理想。

queue depth 為 1 時可顯示原始延遲，也就是單執行緒程序實際感受到的延遲：

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

commit 測試可預測資料庫行為。它會寫入 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 數值，接近單一資料庫連線每秒可提交的小型交易數上限，因為 commit 必須等待相同的 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 的延遲達數 ms，則表示存在網路路徑，無論方案名稱為何。循序讀取速度若在接近 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 特徵

load average 偏高、CPU 閒置，且 wa 中的 vmstat 值很大，表示程序正在等待磁碟。最明確的 kernel 訊號，是 dmesg -T 中的這則訊息：

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

這行訊息表示某個 kernel thread 等待儲存裝置回應超過 2 分鐘，因此 hung task watchdog 記錄了這個事件。jbd2 是 ext4 journal thread，表示整個檔案系統都在等待，而不是單一程式行為異常。在 VPS 上，這通常表示儲存後端有問題，或 IOPS 額度已用盡。

應用程式的症狀也符合相同模式。中位數回應時間仍可接受，但最慢的請求逐漸形成很長的尾端，因為只有碰到磁碟的請求會受到影響。apt upgrade 會在 Unpacking 階段停留數分鐘，因為 dpkg 在寫入時會執行 flush。大型 repository 中的 git status 需要數秒。這些都是 metadata 與 flush 成本，因此增加頻寬也無法改善問題。

磁碟成為瓶頸時的處理方式

先買 RAM，再考慮 IOPS。 如果工作集能放入 page cache，讀取就完全不必存取磁碟。將記憶體加倍通常比改用更快的儲存類別更有效，而且成本通常更低。

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

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

讓 thin volume 持續執行 discard。 在 thin provisioned storage 上，後端必須等檔案系統通知後，才知道某個 block 已經釋出。從未執行 trim 的 volume，其寫入效能會逐漸下降。Ubuntu 提供每週執行的 timer：

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av 會列出每個掛載點修剪的位元組數。如果訊息表示不支援 discard operation，代表 virtual disk 未將 discard 傳遞給 host，因此不需要處理任何問題。

不要調整 IO scheduler。 在 virtio disk 上，cat /sys/block/vda/queue/scheduler 通常已顯示 none，而實際的排程是在 host 上執行，您無法存取該處。noatime 也不需要調整：Ubuntu 預設會以 relatime 掛載，已可避免幾乎所有 atime 寫入。

選擇方案

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

從第 1 天開始測量，同時執行新 VPS 的前 10 分鐘中的操作，並將輸出保存至檔案。基準資料可協助你日後證明主機變慢，而不是程式碼造成問題。優先選擇會以書面說明儲存類型及 IOPS 上限的供應商。如果方案標示為 NVMe，但 queue depth 1 的讀取需要 4 ms，表示你使用的是部署在配備 NVMe 主機上的網路儲存裝置。這是可以銷售的產品，但與你實際購買的產品不同。

FAQ

NVMe 在 VPS 上一定比 SATA SSD 快嗎？

不一定。在 queue depth 1 時，兩者的差距很小；4k 讀取延遲約為 80 到 150 microseconds，單執行緒程式通常無法分辨。當同時有大量請求等待處理時，NVMe 才會拉開差距，因為 AHCI 只有一個深度為 32 個命令的佇列，而 NVMe 提供數千個更深的佇列。在共用主機上，其他 guest 產生的負載對延遲的影響可能大於儲存媒體本身。因此，請使用 fio 測量自己的 volume，不要只看方案名稱。

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

無法直接確認，因為 virtio 會隱藏實體裝置。lsblk 顯示 vda，且沒有 model string；nvme list 不會傳回任何內容；/sys/block/vda/queue/rotational 只會回報 hypervisor 宣告的資訊。請改為測量實際行為。queue depth 1 的隨機 4k 讀取若低於約 0.3 ms，表示使用本機 flash。若延遲為數毫秒，表示路徑中可能經過 network hop。循序讀取若停在接近 550 MB/s，表示使用 SATA link。

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

通常不會。第一次請求後，Linux 會將檔案從 page cache（位於 RAM）提供，因此磁碟會停止處理請求。小型 VPS 的頁面速度通常受應用程式 CPU 執行時間與頻寬限制。若網站每次請求都寫入資料，磁碟才會重新進入關鍵路徑。例如，經常執行 commit 的 database-backed 購物車，每次 commit 都必須等待 flush 完成。

VPS 的 fio 結果多少算理想？

截至 July 2026，本機 flash 上的小型 VPS 通常能在 queue depth 32 下提供數萬 IOPS 的 4k 隨機讀取，queue depth 1 的延遲低於 0.3 ms。Network block storage 通常提供數千 IOPS，延遲則為數毫秒。請在不同時段執行測試 3 次。若各次結果差異很大，這比平均值更能說明問題，因為它反映主機上其他 guest 對你的影響程度。

應該將 database 放在 network block storage 上嗎？

可以，許多 managed service 也採用這種方式，但 commit path 會受到影響。每次 flush 都必須經過 network，因此單一連線每秒能 commit 的小型 transaction 會少於使用本機 flash 的情況。相對地，你可以取得即使主機故障仍能保留的 durability。若為 write-heavy database 選用 network storage，請將工作分組為較大的 transaction，讓較少的 flush 一次處理更多資料列。