Random IO vs Sequential IO: con số nào quyết định VPS?

Trả lời nhanh: Sequential IO, đọc/ghi khối lớn liền mạch (chép file, xem video), là con số MB/s to đẹp trên quảng cáo. Random IO, hàng vạn lượt đọc/ghi 4KB rải rác khắp ổ, mới là mẫu truy cập của web, database, và mọi việc dev. Một ổ có thể đọc tuần tự 7 GB/s nhưng chỉ đáp ứng vài nghìn IOPS ngẫu nhiên nếu phẩm chất kém, và website của bạn sống bằng con số thứ hai. Quy tắc đọc bảng thông số: bỏ qua MB/s, tìm 4K random IOPS + latency; không ghi thì tự đo bằng fio.

Trên mọi trang bán ổ và VPS, con số to nhất luôn là MB/s tuần tự, vì nó đẹp. Nhưng hầu như không việc gì bạn giao cho VPS chạy theo mẫu đó. Bài này vẽ rõ hai mẫu truy cập, xếp các workload quen thuộc vào đúng mẫu, và cho công cụ tự đo, để lần tới nhìn quảng cáo 'tốc độ 7.000 MB/s', bạn biết chính xác nó liên quan gì (và không liên quan gì) đến mình.

Hai mẫu truy cập - hình dung bằng thư viện

Sequential như đọc một cuốn tiểu thuyết: mở trang đầu, lật liên tục đến hết, tốc độ phụ thuộc lật nhanh cỡ nào (băng thông). Random như tra cứu làm luận văn: mỗi phút nhảy sang kệ khác lấy đúng một trang, tốc độ phụ thuộc đi đến kệ nhanh cỡ nào (latency) và tra được bao nhiêu lượt mỗi giây (IOPS). Ổ cơ có 'đôi chân' cơ khí nên tra cứu cực chậm (100-200 lượt/giây); flash 'dịch chuyển tức thời' nên tra hàng trăm nghìn lượt, và NVMe là phiên bản flash được cởi trói giao thức để tra song song tối đa.

Xếp workload của bạn vào đúng mẫu

• Random là chính: mọi truy vấn database (mỗi row/index node một lượt nhỏ), dựng trang web động, npm ci/composer install (vạn file), Docker pull/build (giải nén vạn file), agent AI grep + đọc trăm file, mail server, git status. Tức là 90% đời sống một VPS.
• Sequential là chính: backup/restore file lớn, chép video, tải model AI vào RAM, streaming file. Quan trọng nhưng thưa, và ổ nào hiện đại cũng đủ nhanh cho chúng.
• Trộn: import SQL (ghi tuần tự + fsync ngẫu nhiên), log ghi tuần tự nhưng đọc lại ngẫu nhiên. Thế giới thật thường trộn, và phần random luôn là phần quyết định cảm giác.

Vì sao quảng cáo chỉ khoe sequential - và đọc thế nào cho tỉnh

Vì con số đẹp gấp trăm lần: cùng một ổ SATA có thể '550 MB/s' (nghe to) nhưng chỉ ~80K IOPS 4K ≈ 320 MB/s lý thuyết mà thực tế web hiếm khi vắt nổi một phần, còn HDD '160 MB/s' tuần tự chỉ đạt... ~0,6 MB/s ở mẫu 4K ngẫu nhiên (150 IOPS × 4KB). Khoảng cách giữa hai mẫu chính là khoảng trống để quảng cáo chọn số kể chuyện. Người mua tỉnh đọc theo thứ tự: (1) 4K random read/write IOPS, (2) latency trung bình và p99, (3) rồi mới liếc MB/s. Bảng giá không ghi mục 1-2? fio trả lời trong 5 phút, các bài đo của cụm này đã cho sẵn lệnh.

Random IO và kiến trúc máy: mảnh ghép cuối

Random IO không đứng một mình, nó cộng hưởng với các mảnh đã học trong cụm: queue depth quyết định random song song sâu cỡ nào (bài hàng đợi lệnh); PLP quyết định random write + fsync có an toàn không (bài enterprise); RAID 10 nhân sức random read qua nhiều ổ (bài kế tiếp); và random_page_cost của Postgres là chỗ bạn khai với database rằng random đã rẻ (bài tuning). Ghép đủ, bạn có bức tranh: chọn ổ theo random, cấu hình phần mềm theo ổ, hai bước đơn giản mà đa số hệ thống chậm ngoài kia thiếu ít nhất một.

Xếp công việc của bạn vào đúng mẫu truy cập

Quy tắc nhớ nhanh: nếu công việc của bạn có cơ sở dữ liệu, chỉ số quyết định là IOPS ngẫu nhiên. Băng thông tuần tự chỉ quan trọng khi bạn chép tệp lớn.

Vì sao quảng cáo chỉ khoe con số tuần tự

Vì con số đó lớn và dễ gây ấn tượng: hàng nghìn megabyte mỗi giây nghe hấp dẫn hơn nhiều so với một con số IOPS. Nhưng với máy chủ chạy web và cơ sở dữ liệu, con số tuần tự gần như không liên quan tới trải nghiệm thật.

Cách đọc quảng cáo cho tỉnh: bỏ qua con số tốc độ đọc ghi tuần tự, hỏi ba câu khác là IOPS ngẫu nhiên khối 4K, độ trễ ở mức phần trăm thứ 99, và có bị giới hạn tốc độ sau một thời gian chạy không.

Tự đo cả hai mẫu

apt install -y fio

# Mau ngau nhien, dung nhat voi web va co so du lieu
fio --name=ngaunhien --ioengine=libaio --direct=1 --bs=4k --rw=randread \
    --iodepth=32 --numjobs=4 --size=2G --runtime=300 --time_based --group_reporting

# Mau tuan tu, dung voi sao luu
fio --name=tuantu --ioengine=libaio --direct=1 --bs=1M --rw=read \
    --iodepth=8 --numjobs=1 --size=4G --runtime=120 --time_based --group_reporting

# Chay 5 phut chu khong phai 30 giay:
# nhieu o chay nhanh luc dau roi tut han khi bo dem day

So hai kết quả sẽ thấy rõ: cùng một ổ, con số tuần tự có thể cao gấp nhiều lần con số ngẫu nhiên quy đổi. Nếu công việc của bạn nằm ở nhóm ngẫu nhiên thì con số tuần tự đẹp không giúp gì.

Câu hỏi thường gặp

4K nghĩa là gì trong '4K random'?

Cỡ mỗi khối đọc/ghi: 4 kilobyte, trùng cỡ trang bộ nhớ và khối căn bản của filesystem/database, nên nó thành chuẩn đo mẫu truy cập nhỏ. Không liên quan gì đến độ phân giải màn hình.

Ổ của tôi ghi 'up to 1M IOPS', tin được không?

'Up to' = điều kiện lý tưởng (QD cực cao, ổ trống, tải ngắn). Số đáng tin là steady-state ở QD thực tế (16-64), như bài enterprise đã dặn: đo dài, đo lúc bận.

Web tĩnh thuần HTML có cần quan tâm random IO không?

Ít hơn hẳn, file tĩnh nhỏ thường nằm gọn trong RAM cache sau vài lượt. Đây đúng là loại site 'ổ nào cũng đủ' như bài NVMe-là-gì đã thành thật. Nhưng chỉ cần thêm database là quay lại thế giới random.

Có cách nào giảm random IO thay vì mua ổ nhanh?

Có và nên làm song song: index đúng (giảm số lượt đọc), cache đủ tầng (chặn lượt đọc từ sớm), RAM rộng (biến đọc ổ thành đọc RAM). Ổ nhanh là tầng đáy đỡ phần còn lại, cả cụm bài này chính là bộ 'song song' đó.

Bài viết liên quan

• IOPS là gì? Vì sao quyết định tốc độ web/database
• Ổ cứng NVMe và SATA: khác nhau từ hàng đợi lệnh
• VPS ổ Enterprise U.2 NVMe RAID 10 tại TND