SWE Wiki
Đăng nhập Nâng cấp
SWE Wiki › Bài tóm tắt › ScyllaDB

Common Performance Pitfalls of Modern Storage I/O

Bài tóm tắt ScyllaDB 2026 3. Quy mô lớn Độ khó: Khó

ScyllaDB · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bài tổng kết của nhà cung cấp database, rút từ các cuộc điều tra hiệu năng trên instance NVMe (AWS i7i). Các con số là của ScyllaDB trên phần cứng của họ. Series: phần 1 ScyllaDB 2026 (IO Scheduler) · phần 2 ScyllaDB 2026 (XFS) · phần 3 (bài này).

Bối cảnh

  • Hai phần trước của series tìm ra hai nguyên nhân làm instance lớn "không scale": hàng đợi công bằng trong IO Scheduler của Seastar tự bóp băng thông còn một phần nhỏ so với thông số, và block size/căn chỉnh của XFS gây read-modify-write. Phần này gom lại thành checklist theo ba tầng: đĩa, filesystem, ứng dụng. Mỗi tầng có giả định riêng về "request tối ưu"; lệch nhau thì hậu quả dồn xuống.

Tầng đĩa

  • Sector vật lý và logic: ghi không căn theo sector vật lý buộc controller SSD đọc cả trang, sửa, ghi lại. Firmware NVMe mới trên i7i báo sai sector vật lý là 512 byte (thật là 4 KB), nên IOTune (công cụ benchmark của ScyllaDB) đo bằng request 512 byte và thấy đĩa kém hơn thật: tới 25% IOPS đọc và 42% IOPS ghi. Số đo này cấu hình IO Scheduler, nên database dùng đĩa như một model kém hơn, theo lời bài là "một cách tốt để mất tiền". Vì sao đọc cũng bị ảnh hưởng thì họ chưa hiểu hết.
  • Hiệu năng duy trì: cả NVMe dành riêng cũng có mức đỉnh và mức duy trì; benchmark từ 10 phút trở lên có thể thấp hơn 3–5%.
  • RAID0: chia theo chunk và stripe; kiểu song song của ứng dụng có thể "cộng hưởng" làm vài đĩa chịu tải nhiều hơn.

Tầng filesystem

  • ScyllaDB từng format XFS block 1K để commitlog ghi nhanh từ 1K trở lên (SSD cũ có sector 512 byte). Trên NVMe tối ưu 4K, ghi tuần tự 128 KB qua blktrace cho thấy khoảng 75% request căn ở 1K/2K: controller tách thành đầu, thân 4K và đuôi, đầu và đuôi chịu RMW chậm và kéo cả request. Format lại 4K thì 100% request căn 4K, lấy lại nhiều thông lượng ghi.
  • Metadata chặn I/O: file lớn dần thì XFS phải cấp extent (B-tree, mutex), cập nhật inode, flush metadata, cập nhật ctime. RWF_NOWAIT không đủ khi metadata đang xếp hàng: lệnh ghi bị đẩy sang worker thread thay vì reactor, thêm context switch và latency spike. Biết trước kích thước thì fallocate() hoặc rẻ hơn là ftruncate() (Seastar có sloppy_size: chạm giới hạn thì nhân đôi kích thước bằng truncate).
  • Xoá dữ liệu cũng đắt: trên NVMe đời cũ, TRIM tích trong filesystem có lúc xả một lượt, làm controller quá tải.

Tầng ứng dụng

  • Little's Law: độ sâu hàng đợi = thông lượng × latency. Đĩa 14,5 GB/s với request 128K là khoảng 113 nghìn request/giây; latency 1 ms thì cần ít nhất 113 request đang bay. Tune cho 40 request đồng thời rồi nâng đĩa nhanh hơn thì dùng phí đĩa mới; quá nhiều thì controller (có năng lực tính hạn chế) bão hoà và latency vọt.
  • Tăng song song thì thông lượng tăng, latency gần như phẳng; tới lúc đĩa bão hoà thì thông lượng đứng và latency tăng gần tuyến tính. Điểm gãy đó là điểm cần tìm.
  • ScyllaDB biểu diễn song song bằng số shard (một shard mỗi core) và số fiber; IO Scheduler điều tiết số request gửi xuống theo mục tiêu latency và năng lực đỉnh đo được của đĩa. Theo bài, tải thật khó khớp với một mô hình tĩnh, nên cần bộ lập lịch có giới hạn latency.
  • Kích thước request: băng thông ≈ IOPS × kích thước. Ví dụ 350 nghìn IOPS ở 4K (i7i.4xlarge) chỉ khoảng 1,3 GB/s trong khi máy làm được 3,5 GB/s. Request nhỏ chạm trần IOPS, CPU, chi phí cố định mỗi I/O (syscall, interrupt, copy) trước trần băng thông. Seastar mặc định 128K cho ghi tuần tự; theo bài, chưa thấy SSD nào không bão hoà được bằng 128K, vẫn giữ latency dưới mili giây.

Bài học cho SWE

  • Đừng tin thông số phần cứng tự báo; đo chéo, và đo đủ lâu. Một số đo sai lan vào cấu hình điều tiết thì cả hệ chạy dưới khả năng mà không lỗi gì (Chi phí hạ tầng và build vs buy).
  • Request lớn hơn và đủ request đang bay để khấu hao chi phí cố định mỗi I/O; nhưng kích thước lô bị chặn bởi latency chấp nhận được (Batching và khấu hao round-trip).
  • Đẩy tải xuống thiết bị nên đi qua bộ điều tiết có mục tiêu latency, như backpressure ở tầng I/O (Load shedding, rate limit và backpressure).
  • Ba tầng (đĩa, filesystem, ứng dụng) đều có "đơn vị tối ưu" riêng; nút thắt hay nằm ở chỗ chúng lệch nhau, như mẫu "trần ghi nằm ở chỗ ít ai nhìn" (Tiger Data 2026, Prometheus 2026).

Liên quan

Batching và khấu hao round-tripChi phí hạ tầng và build vs buyLoad shedding, rate limit và backpressure
#NVMe#Physical sector size#Read-modify-write#XFS block size#RAID0#fallocate#RWF_NOWAIT#Little's Law#Queue depth#Request size#Seastar IO Scheduler#AWS i7i

Được nhắc tới trong

Chủ đề (3)
Công ty (1)
Bài tóm tắt (5)