Uncached I/O in Prometheus

Prometheus · 2026 · 4. Điều chỉnh · Độ khó: Khó — bài gốc

Bài ngắn của maintainer giới thiệu feature flag thử nghiệm. Bài toán chung: dữ liệu ghi xong mà ít khi đọc lại vẫn chiếm page cache, làm số đo bộ nhớ của container khó hiểu.

Bối cảnh

• Người dùng Kubernetes thường nhầm giữa container_memory_usage_bytes, container_memory_working_set_bytes, container_memory_rss; chọn sai thì giới hạn bộ nhớ nói dối và container bị OOMKill (có một issue Kubernetes mở 9 năm về chuyện này). Lý do: page cache có thể chiếm phần lớn "bộ nhớ đang dùng" dù phần lớn thu hồi được.
• Prometheus là một database, ghi rất nhiều xuống đĩa. Ghi lúc compaction là ví dụ rõ nhất của dữ liệu không đáng cache: block ghi xong chỉ một phần nhỏ được query lại sớm, và không đoán trước được phần nào.

Thay đổi chính

• Feature flag use-uncached-io (từ v3.5.0, chỉ Linux) ghi bằng direct I/O, bỏ qua page cache.
• Khó ở chỗ direct I/O đòi căn lề: offset trong file, địa chỉ bộ đệm, kích thước ghi đều phải là bội số kích thước sector logic (thường 512 hoặc 4096 byte). Viết một writer kiểu bufio.Writer (directIOWriter) lo việc căn lề; trên kernel 6.1+ lấy giá trị căn lề chính xác bằng statx, kernel cũ dùng giá trị an toàn.
• Hiện chỉ phủ ghi chunk lúc compaction, nhưng đó là phần lớn I/O của Prometheus. Benchmark: page cache (container_memory_cache) giảm 20–50%. Ràng buộc cứng: không làm CPU hay disk I/O tệ đi đo được.
• Việc còn lại: phủ thêm index và WAL; thêm test (chạy toàn bộ test TSDB với build tag ép direct I/O, có ý tưởng kiểm chứng hình thức rằng writer không vi phạm căn lề); thử RWF_DONTCACHE (kernel 6.14, đi qua page cache nhưng bỏ page ngay sau đó, không cần căn lề).

Vì sao

• Bộ nhớ dễ đoán hơn, ít đẩy dữ liệu nóng (mà query cần) ra khỏi cache dùng chung; có thể giảm CPU cho việc cấp phát và thu hồi page cache.

Bài học cho SWE

• Page cache là tài nguyên dùng chung: ghi dữ liệu lạnh qua cache đẩy dữ liệu nóng ra ngoài. Với dữ liệu ghi một lần ít đọc lại, bỏ qua cache có thể đúng hơn.
• Số đo bộ nhớ của container cần hiểu rõ phần nào thu hồi được; giới hạn đặt theo số sai sẽ gây OOMKill hoặc lãng phí (Observability và monitoring).
• Tối ưu cấp thấp (direct I/O) có ràng buộc khắt khe; đặt sau feature flag, có điều kiện "không thoái lui" đo được, và mở rộng dần từng đường ghi.

Liên quan

• Prometheus 2019 · Miro 2020 · WarpStream 2025
• Observability và monitoring