[Ceph Turning] – Tham số OSD recovery max chunk

1. Phân biệt chunk và object

Chunk là gì?

Chunk là kích thước tối đa dữ liệu trong mỗi gói gửi giữa 2 OSD khi thực hiện recovery/backfill.

Object là gì?

• Object trong Ceph (RGW object hoặc RADOS object) có thể nhỏ hơn hoặc lớn hơn chunk size.
• Nếu object nhỏ hơn chunk size → cả object vẫn được chuyển trong 1 op (chunk).
• Nếu object lớn hơn chunk size → nó bị chia thành nhiều op (chunk) nhỏ.

2. Khi giảm mỗi chunk từ 8 MiB → 1 MiB thì chuyện gì xảy ra?

• Nếu object size > 1 MiB (ví dụ 4 MiB hay 8 MiB):
  • Mỗi object sẽ bị chia thành nhiều gói nhỏ hơn → tổng số op tăng lên → scheduler phân phát op recovery rải hơn → HDD đỡ bị burst đọc/ghi lớn.
  • Kết quả: objects/s có thể giảm nếu I/O bị giới hạn bởi seek/queue depth, nhưng không chắc chắn giảm nhiều — vì metric objects/s Ceph báo là số object hoàn tất, không phải số chunk.
• Nếu object size < 1 MiB:
  • Chunk nhỏ hơn mặc định không có tác dụng nhiều, vì mỗi object vẫn vừa trong 1 chunk.
  • Objects/s gần như không đổi, băng thông tổng cũng không đổi.

Ví dụ giả sử.

• Object size trung bình: 8 MiB
• Chunk size: 8 MiB (default) → 1 object = 1 chunk → 1200 object/s = ~9.6 GiB/s data recovery (lý thuyết)
• Chunk size: 1 MiB → 1 object = 8 chunk → với HDD, mỗi chunk sẽ phải chờ thêm → object/s giảm đáng kể, không còn giữ nguyên 1200.

Như vậy nó không giữ nguyên object/s nhưng giảm MB/s — thường nó giảm cả 2, vì HDD 7.2k không xử lý song song quá nhiều chunk nhỏ hiệu quả.

3. Tham số này hoàn toàn an toàn khi đổi trên farm lớn.

• Có thể đổi trực tiếp trên cluster đang chạy, kể cả farm cực lớn, vì:
  • Đây là runtime I/O throttle parameter.
  • Không tác động tới dữ liệu đã lưu.
  • Không yêu cầu restart toàn cluster (Ceph apply config động).
• Ceph sẽ chỉ dùng giá trị mới cho các recovery/backfill từ thời điểm đổi trở đi.

4. Cách can thiệp an toàn trên farm lớn

Kiểm tra giá trị hiện tại:

ceph config get osd osd_recovery_max_chunk 

(Mặc định trên bản mới là 8MiB)

Giảm từ từ, ví dụ:

ceph config set osd osd_recovery_max_chunk 4MiB 

Chờ 5–10 phút quan sát load, rồi cân nhắc hạ tiếp xuống 2MiB hoặc 1MiB.

Có thể rollback nhanh:

ceph config set osd osd_recovery_max_chunk 8MiB

Áp dụng cluster-wide để đồng nhất toàn cluster, tránh OSD lẻ chạy chunk khác nhau.

5. Một số lưu ý và gợi ý combo khuyên dùng

Nếu giảm mỗi osd_recovery_max_chunk thì các gói bị cắt nhỏ có thể làm tốn IOPS chung của OSD. Muốn hạ tải và ổn định, chúng ta nên kết hợp với các option giúp giãn cách thời gian recovery của mỗi op lại.

Đây là combo mình khuyên dùng (an toàn cho HDD 7.2k + EC 6+2):

(1) Giảm song song

ceph config set osd osd_recovery_max_active 1
ceph config set osd osd_max_backfills 1

→ Ít luồng recovery chạy cùng lúc hơn.

(2) Thêm thời gian nghỉ giữa các op

# nếu bản có tham số _hdd:
ceph config set osd osd_recovery_sleep_hdd 0.2

# nếu không có:
ceph config set osd osd_recovery_sleep 0.2

→ Giãn cách các op, tránh queue làm tốn IOPS. Tăng dần 0.2 → 0.3 → 0.5 nếu còn gắt.

(3) Hạ kích thước gói (bắt đầu 2MiB rồi hạ 1MiB nếu cần).

ceph config set osd osd_recovery_max_chunk 1MiB

→ Mỗi op nhẹ hơn, bớt burst I/O. Nhưng vì op nhiều hơn, nhất định cần (1) + (2) để tránh tốn IOPS.

(4) Ưu tiên client, hạ ưu tiên recovery (nếu đang dùng WPQ)

ceph config set osd osd_client_op_priority 63
ceph config set osd osd_recovery_op_priority 1

→ Khi có tải client, recovery tự nhường đường.

(5) Nếu đang dùng mClock

ceph config set osd osd_op_queue mclock_scheduler
ceph config set osd osd_mclock_profile high_client_ops

→ Profile mClock này sẽ nới tay cho client, bóp recovery. (Nếu cluster bạn vẫn WPQ thì giữ WPQ + (4) là đủ.)

(6) Tránh scrub lúc recovery

ceph config set osd osd_scrub_priority 1
ceph config set osd osd_scrub_begin_hour 1
ceph config set osd osd_scrub_end_hour 6
ceph config set osd osd_scrub_sleep 0.1

→ Đừng để scrub cộng dồn I/O với backfill.

Vì sao phải đi theo combo này?

• Chunk nhỏ → nhiều op hơn; nếu không giảm song song và không thêm sleep, scheduler sẽ bắn dồn dập các op nhỏ → HDD seek liên tục, IOPS bão, thậm chí còn gắt hơn so với 1 op 8 MB.
• Kết hợp (1)+(2)+(3) biến tải recovery thành nhiều gói nhỏ nhưng thưa và ít luồng, HDD thở đều hơn → thông thường objects/s và MB/s đều giảm về mức êm, tránh slow/blocked.

6. Tại sao dùng chunk là 2 MiB là lý tưởng cho HDD.

• Mỗi op recovery/backfill của OSD sẽ đọc và ghi tối đa osd_recovery_max_chunk dữ liệu từ một object.
• Mặc định 8 MiB nghĩa là mỗi lần OSD lấy một cục dữ liệu 8 MiB để copy từ nguồn sang đích.
• Với HDD 7200 RPM, thao tác này thường liên quan tới nhiều seek nếu dữ liệu không nằm liên tiếp → thời gian đọc 8 MiB bị kéo dài hơn nhiều so với đọc 2 MiB.
• HDD có thời gian truy cập (seek time) cố định (~8-12 ms cho 7.2k RPM).
• Nếu gói quá lớn (8 MiB), mỗi op sẽ:
  • Giữ chặt đầu đọc lâu hơn cho backfill (8 MiB sequential read).
  • Chặn các request client trong queue I/O → latency của client I/O tăng.
• Nếu giảm xuống 2 MiB, mỗi op sẽ:
  • Mỗi op hoàn tất nhanh hơn → scheduler xen kẽ được nhiều I/O của client vào giữa các block backfill.
  • Tải recovery được phân tán đều, giảm burst throughput và giảm spike latency.

Thực tế benchmark (Ceph community & kinh nghiệm vận hành)

• Trên HDD 7.2k, khi osd_max_backfills=1 + osd_recovery_max_active=1:
  • 8 MiB → recovery ~120–150 MB/s nhưng latency client tăng gấp 5–10 lần trong peak.
  • 2 MiB → recovery ~60–80 MB/s, nhưng latency client gần như không đổi so với idle.
• Đó là lý do Ceph doc khuyến nghị 2 MiB như một compromise.

• Như vậy với:
  • 8 MiB → throughput cao, nhưng dễ gây slow request với HDD.
  • 2 MiB → throughput vừa phải, HDD dễ thở, client I/O không bị chặn quá lâu.
  • 1 MiB → cực an toàn cho client, nhưng recovery có thể quá chậm trong cluster lớn.

Đây là mô tả luồng để dễ hiểu hơn

• R = recovery đọc 1 chunk.
• C = 1 client I/O.
• Mỗi ký tự là khoảng thời gian HDD bận xử lý.

Trường hợp chunk to (8 MiB)

[R R R] C C [R R R] C [R R R] -> | Seek + Read (23 ms) |  → nhả đầu đọc

• Mỗi [R R R] là một recovery chunk giữ đầu đọc lâu (seek + đọc 8 MiB).
• Client C chỉ được xen vào sau khi recovery chunk kết thúc ⇒ latency tăng, slow request dễ xảy ra.

Trường hợp chunk nhỏ (2 MiB)

[R] C [R] C [R] C [R] C [R] C -> | Seek + Read (17 ms) | → nhả đầu đọc

• Recovery hoàn tất nhanh hơn, nhả đầu đọc thường xuyên hơn.
• Client I/O C được xen kẽ đều ⇒ giảm nguy cơ slow request.

Như vậy thời gian chiếm dụng ngắn hơn dễ nhường slot cho client I/O hơn.

Nếu bạn đang ở production farm dùng HDD 7200RPM, chunk 2–4 MiB thường là lựa chọn tốt giữa tốc độ recovery và tránh slow request.

7. Kết luận.

• Nếu object size lớn hơn chunk → giảm osd_recovery_max_chunk vừa giúp giảm MB/s, vừa giảm object/s.
• Nếu object size nhỏ hơn chunk → giảm chunk size chỉ giảm MB/s một chút (do overhead), object/s gần như giữ nguyên.
• Với cluster HDD 7.2k + EC 6+2, object size RGW thường đủ lớn để chunk nhỏ hơn sẽ hạ cả object/s lẫn MB/s, giúp giảm slow/block request.
• osd_recovery_max_chunk mặc dù không đụng đến code xử lý client trực tiếp, nhưng nó thay đổi thời gian chiếm dụng tài nguyên của mỗi op recovery.

Tham số osd_recovery_max_chunk thì khác với rgw_obj_stripe_size ở chỗ:

• rgw_obj_stripe_size thay đổi layout dữ liệu trên disk → tác động lâu dài, ảnh hưởng cả object mới và bảo trì object cũ → rất rủi ro nếu đổi giữa chừng.
• osd_recovery_max_chunk chỉ thay đổi cách Ceph di chuyển dữ liệu trong quá trình recovery/backfill → không thay đổi dữ liệu gốc trên OSD, không đụng layout object.