#hieu-nang

422 bài viết
DevOps 31/08/2026 7 phút

Manifest khai cpu=50m nhưng pod chạy với cpu=410m — VPA sửa con số giữa đường, và kubectl get deployment vẫn thản nhiên hiện số cũ

HPA thêm bản, VPA sửa requests của từng bản. Đo VPA trên cụm thật: khuyến nghị đầu tiên sau ~60 giây (target 410m dùng được, nhưng upperBound 8.856 nhân là vô nghĩa vì chưa đủ lịch sử). Auto mode làm hai việc dễ tưởng là một: bộ admission ghi đè requests lúc tạo pod (manifest 50m → pod 410m, mà get deployment vẫn hiện 50m — vỡ nguồn-sự-thật của GitOps), và bộ updater chỉ giết pod khi requests nằm NGOÀI khoảng tin cậy. Vì sao VPA hay trông như không làm gì, và vì sao VPA với HPA-theo-CPU đá nhau.

#devops#zero-to-hero#hieu-nang#kubernetes
26
DevOps 31/08/2026 9 phút

Hai pod cùng một dòng mã, đồ thị CPU vẽ y hệt nhau — nhưng một cái chậm gấp 23 lần, và cái chỉ số ai cũng nhìn không hề thấy điều đó

Pod chạy được nhưng chậm khó lần hơn pod hỏng hẳn, vì mọi thứ đều xanh. Hai pod khác nhau đúng mỗi limits.cpu: p50 gần như bằng nhau (4,9 so 3,9 ms) mà p95 chênh 23 lần — và ~96 ms không ngẫu nhiên, đó chính là chu kỳ 100 ms của CFS. Đồ thị 'CPU usage' vẽ hai pod trùng khít vì usage giống nhau; bằng chứng nằm ở cpu.stat: 36/50 chu kỳ bị bóp, 3,28 giây bị treo. Và từ K8s 1.33, đổi limit không cần khởi động lại pod nên p95 rơi từ 95,9 xuống 4,1 ms ngay trong lúc gỡ.

#devops#zero-to-hero#hieu-nang#kubernetes
27
Message Queue 30/08/2026 8 phút

'Luôn dùng cooperative-sticky' — tôi đo thử và thấy nó khiến tổng thời gian partition ngừng chạy cao gấp 375 lần lời khuyên đó đang cố tránh

Cân bằng lại nhóm consumer được vẽ nhiều mà đo ít. Tôi bắt từng sự kiện kèm dấu thời gian: kiểu 'nhả hết' xong trong 4 ms không ai để ý, còn kiểu hợp tác giữ được partition đang chạy nhưng mỗi partition nhường mất 3 giây — tổng đắt gấp 375 lần. Lời khuyên 'luôn dùng cooperative' chỉ đúng khi ngắt một partition là đắt.

#kafka#message-queue#zero-to-hero#hieu-nang
35
Message Queue 30/08/2026 8 phút

Cùng một lần sập, ba cách chốt offset: một cách trùng 1.150 tin, một cách trùng 50, một cách mất hẳn 50 tin mà không một lỗi nào — và không cách nào cho ra đúng 5.000

Chốt offset là chỗ dữ liệu thật sự mất hoặc trùng. Tôi dựng một lần sập giống hệt nhau rồi chạy ba cách: chốt trước khi xử lý mất tin, chốt sau khi xử lý trùng tin, không cách nào từ Kafka cho ra đúng một lần. Thứ tự giữa 'làm việc' và 'ghi nhận đã làm' quyết định crash làm mất hay làm trùng.

#kafka#message-queue#zero-to-hero#hieu-nang
34
Message Queue 30/08/2026 7 phút

Sáu partition, hai consumer, tưởng chia 3-3 — Kafka chia 2-4, và một consumer làm gấp đôi mà không ai hiểu vì sao

Chiến lược chia mặc định (RangeAssignor) chia riêng từng topic và làm tròn cùng một phía, nên phần dư dồn hết lên một consumer: hai topic lệch 4:2, năm topic lệch 10:5. Cộng với chuyện khởi động lại một consumer gây tới hai lần cân bằng toàn nhóm — và một dòng group.instance.id xoá sạch cả hai.

#kafka#message-queue#zero-to-hero#hieu-nang
36
Message Queue 30/08/2026 8 phút

Kafka mặc định cho độ trễ 0,35 mili giây — một dòng fetch.min.bytes đẩy nó lên 503 ms, chậm hơn 1.439 lần mà không một lỗi nào, và cắn mạnh nhất lúc vắng khách

'Kafka có độ trễ cao' là câu hay nói. Tôi đo thật, tách từng chặng: mặc định dưới một phần ba mili giây. Thứ gây độ trễ nghìn lần là hai bộ hẹn giờ chờ-gom-lô (linger.ms, fetch.min.bytes) — gần như miễn phí khi tải cao, nhưng bằng đúng cả khoảng chờ khi tải thấp, nên kiểu hỏng tệ nhất rơi vào lúc ba giờ sáng không ai nhìn bảng số.

#kafka#message-queue#zero-to-hero#hieu-nang
30