cgroups — trần CPU, RAM và I/O của một container

TL;DR: cgroup là cơ chế kernel gom một nhóm tiến trình lại rồi áp trần tài nguyên lên cả nhóm — và đây là thứ thật sự đứng sau chữ "giới hạn" của mọi container. Trần CPU nằm ở cpu.max dạng hạn ngạch trên mỗi chu kỳ; vượt hạn ngạch thì cả nhóm bị treo tới đầu chu kỳ sau, sinh ra những đợt độ trễ nhọn mà biểu đồ CPU trung bình không hề thấy. Trần bộ nhớ có hai mức tách bạch: memory.high bóp lại, memory.max giết. Đừng nhầm với nice — nice chỉ đổi thứ tự ưu tiên lúc có tranh chấp, không đặt được trần nào cả.

Một service chạy trong Kubernetes có p99 vượt 2 giây. Biểu đồ CPU của pod thì đẹp: trung bình dùng chưa tới một nửa hạn mức. Không ai tìm ra chỗ chậm trong code, vì chỗ chậm không nằm trong code.

Đội hạ tầng của Indeed đã kể lại đúng ca này: sau khi sửa cách đặt giới hạn CPU, độ trễ phản hồi tệ nhất của một ứng dụng của họ rơi từ hơn hai giây xuống 30 mili-giây. Không dòng code ứng dụng nào thay đổi.

1. Analogy — aptomat và lời khuyên tiết kiệm điện

Trong một toà nhà, có hai cách "giới hạn" điện của một căn hộ.

Cách thứ nhất là dán tờ giấy: "giờ cao điểm xin dùng ít thôi". Nếu hàng xóm không dùng gì, căn hộ đó vẫn bật hết máy lạnh mà chẳng ai ngăn. Tờ giấy chỉ có tác dụng lúc tranh chấp.

Cách thứ hai là lắp aptomat 5 ampe. Không quan tâm hàng xóm dùng bao nhiêu, không quan tâm nhà máy điện đang dư thừa: vượt ngưỡng là ngắt.

nice là tờ giấy. cpu.max của cgroup là cái aptomat. Nhầm hai thứ này là lý do rất nhiều người viết renice 19 cho một job nền rồi ngạc nhiên khi nó vẫn nghiến trọn một lõi lúc máy rảnh.

2. cgroup nằm ở đâu và nó gom cái gì?

cgroup (control group) là cơ chế kernel gom một tập tiến trình thành một nhóm có tên, rồi gắn các bộ điều khiển (controller) đo đếm và áp trần lên cả nhóm đó. Phiên bản 2 hợp nhất mọi controller vào một cây duy nhất, thay vì mỗi loại tài nguyên một cây rời rạc như phiên bản 1.

Cây ấy hiện ra dưới dạng thư mục, mount tại /sys/fs/cgroup:

# Mot tien trinh dang thuoc cgroup nao
cat /proc/self/cgroup
# 0::/user.slice/user-1000.slice/session-3.scope

# Container chay qua systemd nam o day
ls /sys/fs/cgroup/system.slice/docker-<id>.scope/
# cpu.max  cpu.stat  memory.max  memory.high  memory.current  io.max ...

Hai đặc tính khiến nó khác hẳn cách giới hạn theo từng tiến trình:

• Trần áp lên cả nhóm. Mười thread trong nhóm chia nhau đúng một hạn ngạch, không phải mỗi thread một suất.
• Con cái thừa hưởng. Tiến trình sinh ra bên trong nhóm nằm luôn trong nhóm, nên không thoát được bằng cách fork.

Đó chính là lý do container dùng cgroup: một container là một nhóm tiến trình cần bị chặn cùng nhau, chứ không phải một tiến trình đơn lẻ.

3. Ba cái trần và cách đọc chúng

CPU — file cpu.max chứa hai số: hạn ngạch và độ dài chu kỳ, đơn vị micro-giây.

cat cpu.max
# max 100000     -> khong gioi han, chu ky 100 ms
# 200000 100000  -> moi chu ky 100 ms duoc dung 200 ms CPU, tuc 2 loi

Cơ chế thi hành mới là chỗ quan trọng: kernel đếm thời gian CPU nhóm đã tiêu trong chu kỳ hiện tại, và khi chạm hạn ngạch thì treo toàn bộ nhóm cho tới đầu chu kỳ sau. Một nhóm 8 thread với hạn ngạch 2 lõi có thể xài hết suất chỉ trong 25 mili-giây đầu, rồi ngồi im 75 mili-giây. Trung bình đúng 2 lõi, nhưng request rơi vào quãng ngồi im thì cộng thêm cả chục mili-giây độ trễ. Đó là chỗ đuôi trễ của case Indeed bị phá.

Bộ nhớ — hai file, hai hành vi khác hẳn nhau:

Kèm theo là memory.current (đang dùng bao nhiêu, đã gồm cả page cache thuộc về nhóm) và memory.oom.group — đặt bằng 1 thì kernel giết cả nhóm một lượt thay vì bắn tỉa một tiến trình, tránh cảnh container còn sống nhưng đã mất tiến trình lõi.

I/O — file io.max giới hạn theo từng thiết bị, khai bằng cặp số major và minor:

echo "259:0 rbps=104857600 wbps=52428800" > io.max
# thiet bi 259:0 duoc doc toi 100 MB/s, ghi toi 50 MB/s

4. Tự điền — container này đang bị bóp bao nhiêu?

Một service báo p99 xấu theo từng đợt. Bạn đọc cpu.stat của cgroup nó và thấy:

nr_periods    850
nr_throttled  127
throttled_usec 1823400

Ty le chu ky bi treo   = ______ %
Trung binh moi lan treo = ______ ms
Ket luan               = ______

Tỉ lệ chu kỳ bị treo là 127 / 850 ≈ 15%. Mỗi lần treo trung bình 1.823.400 / 127 ≈ 14.357 micro-giây, tức khoảng 14 mili-giây.

Đọc thành lời: cứ khoảng bảy chu kỳ thì có một chu kỳ mà nhóm xài hết hạn ngạch rồi bị treo, và mỗi lần treo dài trung bình 14 mili-giây. Request nào rơi trúng quãng đó lãnh trọn khoản cộng thêm ấy, bất kể nó chỉ cần vài trăm micro-giây để xử lý. Với dịch vụ nhạy độ trễ, 15% là mức thấy rõ trên p99 — bản thân ngưỡng "bao nhiêu phần trăm là quá nhiều" thì tuỳ ngân sách độ trễ của từng dịch vụ, đó là kinh nghiệm vận hành chứ không phải hằng số.

Mâu thuẫn với biểu đồ trung bình cũng được giải thích luôn: mức dùng trung bình tính trên toàn khoảng, nên nó làm phẳng đúng những khoảng treo ngắn tạo ra đuôi trễ. Trung bình đẹp và p99 xấu hoàn toàn sống chung được, và nr_throttled là chỗ chúng gặp nhau.

Hai hướng sửa, tuỳ nguyên nhân: nới hạn ngạch cho đúng nhu cầu đỉnh, hoặc giảm số thread để nhóm không đốt hết suất trong một khoảnh khắc ngắn. Hướng thứ hai hay bị bỏ qua nhưng thường mới là hướng đúng — đó là nội dung của pitfall ngay dưới.

5. Pitfall của riêng concept này

❌ Nhầm 1 — dùng nice để giới hạn CPU của một dịch vụ.

✅ nice chỉ đổi tỉ lệ chia khi có tranh chấp. Máy rảnh thì tiến trình nice 19 vẫn ăn trọn một lõi. Muốn trần cứng thì đặt cpu.max, hoặc CPUQuota= nếu quản bằng systemd.

❌ Nhầm 2 — tin /proc/cpuinfo bên trong container.

✅ File đó không bị che theo cgroup: tiến trình bị giới hạn 2 lõi vẫn nhìn thấy đủ 64 lõi của máy chủ, rồi dựng thread pool theo 64 và đâm thẳng vào hạn ngạch. Runtime đời mới tự đọc cgroup, đời cũ thì phải đặt tay số thread.

❌ Nhầm 3 — đặt hạn ngạch CPU thấp cho service nhạy độ trễ rồi chỉ theo dõi mức dùng trung bình.

✅ Mức trung bình che mất các đợt treo. Theo dõi nr_throttled và throttled_usec, vì đó mới là chỗ độ trễ đuôi được sinh ra.

❌ Nhầm 4 — coi memory.high và memory.max là hai cách viết của cùng một thứ.

✅ Một cái bóp, một cái giết. Đặt memory.high thấp hơn memory.max cho bạn một vùng đệm: nhóm chậm lại và bị ép thu hồi trang trước, thay vì đang chạy ngon thì bị bắn.

6. 📚 Đào sâu (tuỳ chọn)

7. Liên hệ các bài khác

• RSS, VSZ và bộ nhớ thật — vì sao memory.current của cgroup không khớp với tổng RSS mà bạn cộng tay.
• OOM kill và ulimit — chuyện gì xảy ra ngay sau khi memory.max bị vượt, và cách đọc dòng log của lần giết đó.
• Mini-challenge — máy chậm, nghẽn ở đâu? — một trong bốn ca ở đó là một container bị treo theo chu kỳ.
• Bao nhiêu thread là đủ — cùng câu hỏi chọn số thread, nhưng ở đó chưa có tầng trần này chen vào.

8. Tóm tắt

• cgroup v2 là một cây thư mục dưới /sys/fs/cgroup; đọc /proc/self/cgroup là biết ngay tiến trình đang nằm ở nhánh nào.
• cpu.max không bóp tốc độ mà cắt hẳn theo chu kỳ, nên hậu quả của nó là độ trễ nhọn thay vì thông lượng giảm đều.
• nr_throttled chia cho nr_periods là chỉ số quan trọng nhất mà hầu hết dashboard container không bày sẵn.
• Cặp memory.high và memory.max cho phép thiết kế một vùng đệm giữa "chậm lại" và "bị giết".
• Trong container, mọi câu hỏi "máy này có bao nhiêu lõi" phải hỏi cgroup, không hỏi /proc/cpuinfo.

9. Tự kiểm tra

Bài tiếp theo: OOM kill và ulimit — khi kernel ra tay