The Deceptively Simple Act of Writing to Disk

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

Phần 2 của series ba phần: phần 1 ScyllaDB 2026 · phần 3 ScyllaDB 2026. Bài nhà cung cấp, số liệu trên phần cứng của họ.

Bối cảnh

Sau khi sửa IO Scheduler ở phần 1, IOTune đo ra số scale đẹp theo cỡ máy. Nhưng với workload gần thật, throughput ghi lại giảm khoảng 10% trên các instance có SSD mới, nhanh. Họ đã chờ cải thiện, nên đây là tín hiệu đáng lo.
Phát hiện kèm theo: vụ request 512 byte ở phần 1 thật ra là lỗi firmware: controller SSD báo sector vật lý 512 byte trong khi thật là 4K. Nhà cung cấp cloud không sửa vì lo tương thích ngược, nên ScyllaDB tự lách.
Dấu hiệu trên dashboard: "I/O Group consumption" (phần năng lực đĩa đang bị request chiếm) dao động, "queue flow ratio" (tốc độ vào so với tốc độ dispatch, nên gần 1,0) có gai; tổng băng thông commitlog + memtable + compaction chỉ khoảng 12,5 GB/s trên RAID 4 NVMe khoảng 14,5 GB/s. Gai ở flow ratio nghĩa là scheduler đang ép đĩa nhiều hơn khả năng thật.

Các hướng đi sai (đáng ghi lại)

Đỉnh hay bền: nghi IOTune chạy mặc định 2 phút đo trúng đỉnh (SSD ổn định sau khoảng 30 phút, thấp hơn khoảng 5%), làm model bị thổi phồng. Đo lại 30 rồi 60 phút: không đỡ.
Saturation length 1 MB: IOTune báo cần request 1 MB mới đạt băng thông tối đa (thường là 128K, độ dài Seastar dùng cho ghi tuần tự). Nếu đúng thì phải đổi kiến trúc. Hoá ra là lỗi của công cụ đo: IOTune chạy song song quá thấp, còn io_tester đo ghi đè file thay vì ghi vào file mới đã truncate. Kết quả phụ: cấp phát extent khá chậm, nhất là khi allocation group đã bận.
RAID chunk: nghi các shard cùng ghi vào một đĩa trong RAID0 (XFS căn file theo 1 MB, chunk RAID 1 MB). Đo cho thấy một đĩa 3,22 GB/s, cả mảng 10,9 GB/s, nên không phải; mô phỏng cũng chia đều.
Song song nội bộ: 64 shard cho băng thông thấp hơn 8 shard, latency tăng mà băng thông giảm, khác đường cong bình thường (băng thông bão hoà rồi latency tăng tuyến tính). Lý do IOTune không thấy: nó đo từng shard một, còn workload thật bắn từ mọi shard cùng lúc.

Nguyên nhân

Lỗi chỉ tái hiện với 64 shard và với RAID tạo bằng script scylla_raid_setup, không xảy ra trên block device thô hay RAID mặc định. So lệnh mkfs.xfs: script đặt block size 1K, mặc định là 4K. Và truncate file tới kích thước cuối trước khi ghi lấy lại băng thông bị mất.
strace cho thấy mọi lệnh ghi bị đẩy khỏi thread reactor sang thread của XFS (RWF_NOWAIT trả EAGAIN, Seastar gửi lại không có cờ). Tắt cờ không tăng throughput; về sau một đồng nghiệp viết patch kernel liên quan cập nhật inode time. Đây không phải nguyên nhân chính.
blktrace cho thấy phân bố căn chỉnh offset: XFS 4K thì đa số request căn 4K; XFS 1K thì đa số căn 1K hoặc 2K; XFS 1K + truncate thì căn 64K. XFS bố trí file trên đĩa rất khác khi biết trước kích thước so với khi file lớn dần.
Request 128K căn lệch 1K/2K trên NVMe tối ưu cho 4K buộc đĩa read-modify-write ở đầu và đuôi mỗi request. Mỗi lần chậm một chút, nhưng vì gần như mọi request đều lệch nên tổng throughput mất đáng kể. (Ngoài lề: request vắt qua ranh giới chunk RAID 1 MB bị tách đôi, một nửa xong trong 161 µs, nửa kia 5.249 µs.)
Sửa: format XFS block 4K. Truncate trước không áp được vì không biết SSTable sẽ lớn bao nhiêu; sloppy_size (nhân đôi kích thước mỗi lần ghi quá cuối) chỉ lấy lại được một nửa. Đã kiểm block 4K không gây khuếch đại đọc trên đĩa cũ sector 512 byte.

Kết quả

Đĩa dùng hết và không còn bị ép (flow ratio phẳng). Commitlog và memtable trông giống trước, có lẽ đó là trần của bài test. Cái lợi nằm ở compaction: chiếm khoảng 10 GB/s khi commitlog + memtable chạy 4,5 GB/s, rồi lên 14,5 GB/s khi hai nhóm kia xong.

Vì sao

Mỗi tầng (đĩa, filesystem, ứng dụng) có giả định riêng về request tối ưu. Một tham số cài đặt (block size của filesystem do script đặt) lệch với phần cứng mới làm trần ghi thấp đi mà không có lỗi nào hiện ra.
Model đĩa đúng mà đĩa vẫn bị quá tải vì đường đi của request trong thực tế khác lúc đo (Load shedding, rate limit và backpressure).

Bài học cho SWE

Benchmark phải giống workload thật ở chỗ quan trọng: song song từ mọi shard cùng lúc, ghi vào file mới chứ không ghi đè, chạy đủ lâu.
Ghi lại các giả thuyết sai cùng lý do bác bỏ; nhiều cái "rất hợp lý" vẫn sai khi đo.
Script cài đặt là một phần của hiệu năng: tham số filesystem chọn từ thời phần cứng cũ có thể thành nút thắt trên phần cứng mới (Chi phí hạ tầng và build vs buy).
Nhà cung cấp phần cứng/cloud có thể không sửa lỗi (firmware) vì tương thích ngược; hãy chuẩn bị đường lách ở phía mình.

The Deceptively Simple Act of Writing to Disk

Bối cảnh

Các hướng đi sai (đáng ghi lại)

Nguyên nhân

Kết quả

Vì sao

Bài học cho SWE

Liên quan

Được nhắc tới trong