NVMe hay SSD SATA trên VPS: khác biệt không?

NVMe có quan trọng trên VPS không?

NVMe quan trọng trên VPS khi phần mềm của bạn thực hiện nhiều thao tác đọc và ghi nhỏ, đồng thời phải chờ từng thao tác hoàn tất. NVMe hầu như không tạo khác biệt đối với một website phân phối các trang đã được cache hoặc một chương trình dành phần lớn thời gian để chờ network. Loại thiết bị lưu trữ chỉ là một yếu tố. Hypervisor nằm phía trước ổ đĩa và các guest khác dùng chung host sẽ quyết định giới hạn hiệu năng thực tế bạn nhận được.

NVMe thay đổi gì và không thay đổi gì

NVMe (non-volatile memory express) không phải là một loại flash memory. Đây là protocol và kết nối dùng để truy cập flash. Thiết bị NVMe kết nối qua các lane PCIe (peripheral component interconnect express) và sử dụng NVMe. SSD SATA (serial ATA) kết nối qua link SATA và sử dụng AHCI (advanced host controller interface). Các chip memory lưu byte của bạn có thể giống hệt nhau trên cả hai loại.

Có hai điểm khác biệt. Cả hai đều liên quan đến đường đi của lệnh, không phải bản thân storage.

Hàng đợi. AHCI cung cấp cho kernel một command queue chứa 32 lệnh. NVMe cho phép dùng hàng nghìn queue, trên thực tế thường là một queue cho mỗi CPU core. Mỗi queue có độ sâu lớn hơn nhiều so với 32. Một process đọc từng block một sẽ không nhận thấy khác biệt này. Một database có 64 request đang chờ xử lý thì có: trên SATA, request thứ 33 phải chờ một slot trong queue trước khi thiết bị nhìn thấy nó; còn thiết bị NVMe nhận tất cả và xử lý đồng thời.

Độ rộng link. Một link SATA III chạy ở 6 Gbit/s, tương đương khoảng 550 MB/s dữ liệu thực tế sau overhead của protocol. Đây là giới hạn cố định, bất kể phía sau là loại flash nào. Bốn lane PCIe truyền được vài gigabyte mỗi giây, nên link không còn là giới hạn.

Latency là nơi kỳ vọng thường sai. Ở queue depth 1, tức chỉ có một request đang được xử lý, SSD SATA phản hồi một lần đọc 4k trong khoảng 100 đến 150 microsecond. NVMe phản hồi trong khoảng 80 đến 100 microsecond. Cả hai đều nhanh, và không workload nào bạn chạy sẽ nhận thấy khác biệt trên một request. Khoảng cách xuất hiện khi có concurrency. Queue depth, tức số request đang được xử lý cùng lúc, là thiết lập quyết định hai loại media trông giống nhau hay rất khác nhau.

Network block storage là một nhóm thứ ba với đặc tính khác. Một lần ghi phải đi qua network đến storage cluster và chỉ được xác nhận khi cluster đã lưu dữ liệu. Vì vậy, latency được đo bằng millisecond thay vì microsecond. Đổi lại latency đó là durability: volume vẫn tồn tại sau khi host gắn với nó bị hỏng, đồng thời có thể được snapshot và resize.

Các số liệu thường được công bố: NVMe, SATA SSD và lưu trữ qua mạng

[
  {
    "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"
  }
]

Thiết bị NVMe cục bộ thường được công bố đạt 184,000 IOPS đọc ngẫu nhiên 4k (số thao tác vào/ra mỗi giây) ở độ sâu hàng đợi 32. Cùng phép kiểm tra đó trên SATA SSD thường đạt khoảng 90,000, do một hàng đợi AHCI duy nhất và liên kết 6 Gbit/s giới hạn. Lưu trữ block qua mạng thường bị giới hạn bởi nhà cung cấp thay vì phần cứng, và 12,500 là mức trần thường được ghi trong tài liệu.

Độ trễ cũng cho thấy điều tương tự, theo đơn vị mà người dùng cảm nhận được. Độ trễ đọc p99, tức 1 phần trăm request chậm nhất, vào khoảng 0.4 ms trên NVMe cục bộ và 1.2 ms trên SATA. Khi đưa mạng vào đường truyền, độ trễ tăng lên 6.5 ms, cao hơn 10 lần so với NVMe.

Đọc tuần tự có khoảng cách lớn nhất nhưng ít hữu ích nhất: 3,400 MB/s so với 550 MB/s. Hầu như không có tác vụ nào trên server đọc một file lớn từ đầu đến cuối ở tốc độ tối đa. Cột ngẫu nhiên và cột độ trễ mô tả đúng hơn cách database, hàng đợi email hoặc package manager thực sự hoạt động.

Những workload nào nhận thấy tốc độ đĩa

Một quy tắc giải thích tất cả: workload chỉ nhận thấy tốc độ đĩa khi phải chờ đĩa. Linux giữ dữ liệu file được dùng gần đây trong RAM, trong page cache, nên lần đọc thứ hai của một file không bao giờ truy cập storage. Nếu working set, tức dữ liệu thực sự đang được sử dụng, vừa với RAM, các lần đọc sẽ trở thành lần đọc từ bộ nhớ sau lượt đầu tiên. Ghi dữ liệu khác với đọc. Mọi lần ghi mà ứng dụng flush bằng fsync() phải được lưu trên stable storage trước khi ứng dụng được phép tiếp tục.

Tác vụ thực hiện commit. PostgreSQL, MySQL và SQLite gọi fsync() hoặc fdatasync() khi commit, và mỗi commit đều phải chờ thiết bị phản hồi. Vì vậy, tốc độ commit của một connection do write latency quyết định, không phải bandwidth. Thiết bị flush trong 0.2 ms cho phép thực hiện nhiều commit mỗi giây hơn thiết bị mất 5 ms, và không có mức throughput nào thay đổi được điều đó. MySQL ghi rõ điều này trong error log khi flush không theo kịp:

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

PostgreSQL báo cáo điều này trong các dòng checkpoint. Giá trị sync= lớn cho biết chính thao tác flush đã chậm:

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

Tác vụ truy cập nhiều file nhỏ. Mỗi file đều phát sinh các thao tác metadata mà một lần đọc tuần tự file lớn không có. npm install, git clone của một repository lớn, giải nén container image, Maildir mail store và backup duyệt qua một cây thư mục lớn đều dành phần lớn thời gian cho các lần truy cập ngẫu nhiên nhỏ. Một job backup restic trên VPS đọc và hash mọi file chưa từng được xử lý, nên thời gian thực tế của backup trên một triệu file phụ thuộc chặt vào random read latency. Điều tương tự cũng đúng với du -sh, vì thao tác này chỉ đọc metadata.

Các database vượt quá dung lượng RAM cũng thuộc nhóm này. Khi index không còn vừa với page cache, mỗi lần lookup sẽ trở thành một lần đọc ngẫu nhiên và đĩa lại nằm trên critical path.

Những workload nào không nhận thấy sự khác biệt của ổ đĩa

Blog hoặc website nhỏ của công ty. Các trang có dung lượng nhỏ. page cache giữ toàn bộ nội dung sau request đầu tiên. Giới hạn nằm ở CPU khi render hoặc băng thông cho asset. Một LAMP stack trên Ubuntu 24.04 phục vụ website ít traffic gần như không thực hiện disk IO sau khi cache đã được làm nóng.

Streaming media. Một stream 4K ở tốc độ 40 Mbit/s đọc 5 MB/s. Mười stream đọc 50 MB/s. Ngay cả block storage qua network cũng phục vụ được tốc độ này mà không gặp vấn đề. Một media server Jellyfin trên VPS bị giới hạn bởi mức network egress được cấp và CPU khi transcode, không phải bởi loại storage.

Suy luận model cục bộ. Chạy Ollama trên VPS để tự host LLM đọc file model một lần, sau đó xử lý trong RAM. NVMe giảm thời gian tải model 20 GB từ vài phút xuống vài giây. Nó không thay đổi số token mỗi giây. Tốc độ này bị giới hạn bởi memory bandwidth và CPU.

Bất kỳ workload nào phải chờ external service. Một worker mất 800 ms cho mỗi job khi thực hiện HTTP request sẽ không chạy nhanh hơn chỉ vì dùng disk tốt hơn.

Vì sao hypervisor quan trọng không kém loại thiết bị lưu trữ

Bạn không giao tiếp trực tiếp với thiết bị. Bạn giao tiếp với một virtual disk do hypervisor cung cấp, thường thông qua virtio. Một số quyết định ở lớp này ảnh hưởng nhiều hơn việc dùng NVMe hay SATA.

Bạn không thể xem loại thiết bị lưu trữ từ bên trong guest. lsblk -d -o NAME,ROTA,SIZE,MODEL hiển thị vda với trường model trống, vì virtio không truyền thông tin nhận dạng ổ đĩa qua guest. cat /sys/block/vda/queue/rotational báo cáo những gì hypervisor quảng cáo, nên giá trị 0 ở đó không chứng minh thiết bị dùng flash. nvme list, thuộc package nvme-cli, không liệt kê gì trên hầu hết VPS, ngay cả khi host chứa đầy ổ NVMe, vì disk của bạn là thiết bị virtio chứ không phải thiết bị NVMe. Khi một gói dịch vụ ghi là NVMe, thông tin đó thường mô tả thiết bị mà host sử dụng. Volume của bạn vẫn có thể được gắn qua network.

Chế độ cache của host làm thay đổi các con số nhiều hơn loại thiết bị. Khi host bật writeback caching, một fsync() trong guest có thể trả về ngay khi host đã lưu dữ liệu trong RAM của chính nó. Kết quả benchmark khi đó có thể cao hơn khả năng của mọi thiết bị vật lý. Điều này cũng có nghĩa là host crash có thể làm mất những lần ghi mà database của bạn cho rằng đã an toàn. Với cache mode none, các con số thấp hơn và phản ánh thực tế hơn.

Giới hạn và burst credit. Nhiều nhà cung cấp giới hạn IOPS theo volume hoặc theo gói dịch vụ. Nhiều network volume cũng dùng burst allowance. Burst allowance là một pool credit. Volume chạy nhanh khi credit còn, sau đó giảm xuống baseline thấp hơn nhiều. Dấu hiệu rất dễ nhận biết. Một thao tác import hoặc restore chạy nhanh trong vài phút, sau đó chậm hẳn và tiếp tục chậm mà bạn không thay đổi cấu hình. Bạn đã dùng hết credit.

Các guest khác. Trên host dùng chung, độ trễ của disk thay đổi theo hoạt động của các guest khác. Đây là lý do bạn cần đo nhiều lần. Chạy cùng một bài kiểm tra vào buổi sáng và chạy lại vào buổi tối, sau đó so sánh mức chênh lệch. Trên host bận, chênh lệch giữa 2 lần chạy trên cùng một volume thường lớn hơn chênh lệch được công bố giữa 2 loại thiết bị.

Cách đo dung lượng disk thực tế trên VPS

Cài fio, công cụ benchmark IO tiêu chuẩn, rồi tiến hành đo. Trước tiên, cần lưu ý 3 điểm. Bài test tạo một file, vì vậy nó sử dụng disk space và được tính vào hạn mức IOPS mà bạn bị tính phí. Giữ thời gian chạy ngắn. Không chạy với queue depth tối đa trên volume đang phục vụ network traffic thực tế, vì bạn sẽ cạnh tranh tài nguyên với chính ứng dụng của mình.

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

Đọc ngẫu nhiên với queue depth 32, là mức độ sâu mà các nhà cung cấp thường công bố:

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

Dòng quan trọng bắt đầu bằng read:

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

--direct=1 bỏ qua guest page cache, nên kết quả mô tả thiết bị thay vì RAM của bạn. Nếu bỏ tùy chọn này, bạn đang đo memory; kết quả đó có thể cao hơn mọi con số mà disk thực tế đạt được. Dùng --size=4G hoặc lớn hơn nếu bạn có đủ dung lượng, vì file 1G có thể nằm hoàn toàn trong cache của host và làm kết quả cao hơn thực tế.

Queue depth 1 cho biết độ trễ thô, tức độ trễ mà một process đơn luồng thực sự cảm nhận:

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

Bài test commit dự đoán hành vi của database. Bài test ghi 4k rồi gọi fdatasync() sau mỗi lần ghi, nên tốc độ báo cáo đã bao gồm thời gian 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

Chỉ số IOPS từ lần chạy này gần với số giao dịch nhỏ mỗi giây cao nhất mà một database connection có thể commit, vì mỗi commit phải chờ cùng một lần flush.

Để lấy mẫu nhanh mà không cần 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

Giá trị mdev, tức độ lệch trung bình, quan trọng không kém giá trị trung bình. Độ lệch lớn trên một máy đang idle cho thấy storage backend được dùng chung và đang bận.

Cách đọc kết quả

Tính đến tháng 7 năm 2026, các cách đọc sau phù hợp với một VPS nhỏ. Hàng chục nghìn IOPS đọc ngẫu nhiên 4k ở queue depth 32, với độ trễ ở queue depth 1 dưới khoảng 0.3 ms, phù hợp với flash cục bộ. Độ trễ ở queue depth 1 lên đến vài mili giây cho thấy có network path, bất kể gói dịch vụ được gọi là gì. Tốc độ đọc tuần tự dừng gần 550 MB/s là dấu hiệu của liên kết SATA. Một con số cao hơn nhiều so với khả năng của bất kỳ thiết bị đơn lẻ nào cho thấy cache nằm trên đường đi, gần như luôn là cache trên host.

Để xem workload đang chạy tác động lên disk như thế nào:

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

Trong output của iostat -x, đọc r_await và w_await, là số mili giây trung bình một request phải chờ, cùng với aqu-sz, là độ dài queue trung bình. Bỏ qua %util trên virtual disk. Giá trị này báo cáo tỷ lệ thời gian có ít nhất một request đang chờ xử lý. Nó không cho biết mức bão hòa trên một thiết bị có thể xử lý nhiều request cùng lúc. Vì vậy, %util ở mức 100 cùng với r_await ở mức 0.2 ms cho thấy disk đang bận nhưng vẫn hoạt động bình thường. Trong vmstat, cột wa là phần trăm thời gian CPU dành cho việc chờ IO. Nếu /proc/pressure/io tồn tại trên kernel của bạn, giá trị some avg10= là tỷ lệ trong 10 giây gần nhất có ít nhất một task bị đình trệ do IO. Đây là chỉ báo trực tiếp nhất cho việc storage có phải bottleneck hay không.

VPS bị giới hạn bởi disk trông như thế nào

Load average cao trong khi CPU idle và wa lớn trong vmstat cho thấy các process đang phải chờ disk. Tín hiệu rõ nhất từ kernel là thông báo này trong dmesg -T:

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

Dòng này xuất hiện vì một kernel thread đã chờ storage phản hồi quá 2 phút, nên hung task watchdog ghi log. jbd2 là thread journal của ext4. Điều này cho thấy toàn bộ filesystem đang phải chờ, không phải chỉ một chương trình hoạt động bất thường. Trên VPS, nguyên nhân thường là storage backend hoặc hạn mức IOPS đã cạn.

Các triệu chứng ở application cũng theo cùng mô hình. Thời gian phản hồi median vẫn chấp nhận được, nhưng các request chậm nhất tạo thành một đuôi dài, vì chỉ những request phải truy cập disk mới bị ảnh hưởng. apt upgrade đứng ở trạng thái Unpacking trong nhiều phút vì dpkg flush dữ liệu khi ghi. git status trong một repository lớn mất vài giây. Đây là chi phí metadata và flush, nên tăng bandwidth sẽ không giúp ích.

Cần làm gì khi đĩa là giới hạn

Mua RAM trước khi mua IOPS. Nếu working set vừa với page cache, các thao tác đọc sẽ không còn truy cập đĩa. Tăng gấp đôi bộ nhớ thường hiệu quả hơn chuyển sang storage class nhanh hơn và thường ít tốn kém hơn.

Giảm số lần flush khi dữ liệu cho phép. Trong PostgreSQL, synchronous_commit = off cho phép commit trả về trước khi dữ liệu được ghi xuống đĩa. Nếu server bị hỏng, bạn có thể mất phần giao dịch trong phân số giây cuối cùng. Database không bị hỏng vì write-ahead log vẫn được ghi theo thứ tự. Đánh đổi này phù hợp với bản sao dùng cho analytics nhưng không phù hợp với hệ thống thanh toán. innodb_flush_log_at_trx_commit = 2 trong MySQL cũng là cùng một cách đánh đổi.

Gộp các file nhỏ. Việc truyền hoặc backup một triệu file nhỏ bị chi phối bởi chi phí trên mỗi file. Vì vậy, trên storage có latency cao, archive trước rồi truyền thành một stream thường nhanh hơn copy từng file trong cây thư mục.

Đảm bảo discard hoạt động trên thin volume. Với storage thin provisioned, backend không biết một block đã được giải phóng cho đến khi filesystem thông báo. Một volume không bao giờ được trim sẽ dần mất hiệu năng ghi. Ubuntu cung cấp một timer chạy hằng tuần cho việc này:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av in ra số byte đã được trim trên mỗi mount point. Thông báo discard operation không được hỗ trợ nghĩa là virtual disk không chuyển discard đến host. Bạn không cần sửa gì.

Bỏ qua việc tinh chỉnh IO scheduler. Trên virtio disk, cat /sys/block/vda/queue/scheduler thường đã hiển thị none, còn việc scheduling thực tế diễn ra trên host, nơi bạn không có quyền truy cập. Bạn cũng có thể bỏ qua noatime: Ubuntu mặc định mount bằng relatime, tùy chọn này đã tránh gần như mọi lần ghi atime.

Chọn gói

Hãy trả thêm cho NVMe khi máy chủ chạy database, mail server, CI runner hoặc quy trình build dùng nhiều package. Không nên trả phí cao hơn cho website đã được cache hoặc ứng dụng dành phần lớn thời gian gọi dịch vụ bên ngoài. Nếu chưa chắc, có lẽ disk không phải giới hạn của bạn, vì hầu hết workload VPS nhỏ sẽ hết RAM hoặc băng thông trước.

Hãy đo ngay trong ngày đầu tiên, trong khi bạn thực hiện mười phút đầu tiên trên VPS mới, và lưu kết quả vào một file. Baseline giúp bạn chứng minh về sau rằng host đã chậm hơn, thay vì code của bạn có vấn đề. Ưu tiên provider công bố rõ storage class và giới hạn IOPS, nếu có, bằng văn bản. Nếu một gói ghi là NVMe nhưng thao tác đọc với queue depth 1 mất 4 ms, thì bạn đang dùng network storage trên một host được trang bị NVMe. Đây là một sản phẩm hợp lý để bán, nhưng khác với thứ bạn đang mua.

FAQ

NVMe có luôn nhanh hơn SSD SATA trên VPS không?

Không. Ở queue depth 1, hai loại này gần tương đương, khoảng 80 đến 150 microseconds cho một lần đọc 4k, và một chương trình chạy single-threaded không thể phân biệt được. NVMe vượt lên khi có nhiều request đang chờ xử lý, vì AHCI chỉ cung cấp một queue sâu 32 command, còn NVMe cung cấp hàng nghìn queue sâu hơn. Trên host dùng chung, tải từ các guest khác có thể làm latency thay đổi nhiều hơn bản thân loại ổ đĩa, vì vậy hãy đo volume của bạn bằng fio thay vì chỉ xem tên plan.

Làm cách nào để kiểm tra VPS của tôi có thực sự dùng NVMe không?

Bạn không thể kiểm tra trực tiếp, vì virtio ẩn thiết bị vật lý. lsblk hiển thị vda nhưng không có chuỗi model, nvme list không trả về gì, còn /sys/block/vda/queue/rotational chỉ báo cáo thông tin hypervisor công bố. Thay vào đó, hãy đo hành vi của thiết bị. Random read 4k ở queue depth 1 có latency dưới khoảng 0.3 ms nghĩa là flash cục bộ. Vài milliseconds nghĩa là đường truyền có network hop. Sequential read dừng gần 550 MB/s cho thấy đang dùng liên kết SATA.

NVMe có làm website của tôi tải nhanh hơn không?

Thông thường là không. Sau request đầu tiên, Linux phục vụ các file từ page cache trong RAM, nên disk không còn hoạt động. Tốc độ trang trên VPS nhỏ thường bị giới hạn bởi thời gian CPU của application và bandwidth. Disk quay lại critical path nếu website ghi dữ liệu trong mỗi request, chẳng hạn một cart dựa trên database thường xuyên commit, vì mỗi commit phải chờ flush hoàn tất.

Kết quả fio nào là tốt đối với VPS?

Tính đến tháng 7 năm 2026, một VPS nhỏ dùng flash cục bộ thường đạt hàng chục nghìn IOPS random read 4k ở queue depth 32, với latency ở queue depth 1 dưới 0.3 ms. Network block storage thường đạt vài nghìn IOPS với latency vài milliseconds. Hãy chạy test 3 lần vào các giờ khác nhau. Chênh lệch lớn giữa các lần chạy cho bạn nhiều thông tin hơn giá trị trung bình, vì nó cho thấy các guest khác trên host ảnh hưởng đến bạn nhiều đến mức nào.

Tôi có nên đặt database trên network block storage không?

Bạn có thể làm vậy, và nhiều dịch vụ managed cũng làm như vậy, nhưng commit path sẽ chịu thêm chi phí. Mỗi flush phải đi qua network, vì vậy một connection đơn lẻ sẽ commit được ít transaction nhỏ hơn mỗi giây so với khi chạy trên flash cục bộ. Đổi lại, bạn có durability vẫn tồn tại khi host gặp sự cố. Nếu chọn network storage cho database có nhiều hoạt động ghi, hãy gộp công việc vào các transaction lớn hơn để ít flush hơn nhưng mỗi flush xử lý được nhiều row hơn.