Đặt giới hạn bộ nhớ container theo MiB
Dung lượng được giao cho bạn bằng gibibyte: một node công bố 16 Gi bộ nhớ cấp phát được, một namespace được cấp hạn mức 64 Gi cho cả nhóm. Nhưng ô bạn phải điền — resources.limits.memory trong tệp khai báo pod, hay con số sau -Xmx — gần như luôn viết bằng mebibyte. Đổi phần Gi được cấp thành con số Mi ấy là phép tính đầu tiên của mọi buổi tinh chỉnh heap, và cũng là phép hay bị làm ẩu nhất.
MiB = GiB × 1024. Mức cấp 6 GiB là 6 × 1024 = 6144 MiB, nên dòng khai báo ghi limits.memory: 6144Mi. Chia cho 1024 để quay ngược lại.Mi không phải là M
Mi là mebibyte (1.048.576 byte) còn M trơ trọi là megabyte. Gõ 512M trong khi định viết 512Mi sẽ âm thầm cắt mất 23,72 MiB, và chẳng có cảnh báo nào cả.-Xmx nói cùng một hệ cơ số
m và g của JVM cũng là nhị phân, nên -Xmx4g và -Xmx4096m xin cùng một mức heap. Nhờ vậy phép nhân 1024 trở thành tiếng nói chung giữa tệp khai báo và cờ của JVM.Heap không phải là cả container
-Xmx. Đặt heap bằng đúng giới hạn thì cgroup chạm trần trước khi bộ thu gom rác kịp thấy sức ép nào.Biến phần Gi được cấp thành con số heap
Nhập con số Gi
Gõ số gibibyte lấy từ hạn mức hoặc từ phần mô tả node vào ô bên trái. Số lẻ vẫn được — 1.5 và 1,5 đều chạy, còn khoảng trắng thì được bỏ qua.
Sao chép con số MiB trần
Nút sao chép đưa các chữ số lên bộ nhớ tạm mà không kèm đơn vị — đúng thứ cần đặt trước Mi trong YAML hoặc sau -Xmx trong tham số JVM.
Chừa phần dự phòng ngoài heap
Cắt một lát từ tổng MiB đó cho mọi thứ nằm ngoài heap. Một phần tư giới hạn là mức dự phòng khởi đầu quen thuộc cho dịch vụ chạy JVM, sau đó siết dần theo biểu đồ sử dụng thực tế.
Soi ngược một pod đang chạy
Bảng theo dõi báo bộ nhớ đang dùng theo MiB. Bấm đảo đơn vị để lật chiều và đọc con số MiB thực tế ấy trở lại thành gibibyte, đem so với dung lượng node bạn được hứa.
Cả hai ô đều nhập được, nên gõ vào phía MiB sẽ quy về GiB mà không cần thao tác nào thêm. Mỗi bên còn có danh sách đơn vị kèm ô tìm kiếm, tiện khi một báo cáo chi phí ghi cùng mức cấp phát đó bằng đơn vị khác.
Giới hạn container và mức heap đặt cạnh nhau
Đây là những mức giới hạn hay gặp nhất trong triển khai thật, đã đổi sang mebibyte rồi tách thành phần dành cho heap và phần dự phòng ngoài heap theo tỷ lệ 75/25. Cột dự phòng chính là khoảng thở giúp pod không lọt vào danh sách OOMKilled.
| Giới hạn container | Cùng mức đó theo MiB | Heap ở mức 75% | Dự phòng ngoài heap |
|---|---|---|---|
| 0,5 Gi | 512 MiB | 384 MiB | 128 MiB |
| 1 Gi | 1.024 MiB | 768 MiB | 256 MiB |
| 2 Gi | 2.048 MiB | 1.536 MiB | 512 MiB |
| 4 Gi | 4.096 MiB | 3.072 MiB | 1.024 MiB |
| 8 Gi | 8.192 MiB | 6.144 MiB | 2.048 MiB |
| 16 Gi | 16.384 MiB | 12.288 MiB | 4.096 MiB |
Container nhỏ mới là chỗ tỷ lệ này cắn đau nhất. Ở mức 512 MiB, phần dự phòng chỉ còn 128 MiB, mà riêng metaspace cộng vài chục ngăn xếp luồng đã ngốn gần hết — vì thế pod Java bé cần tỷ lệ heap thấp hơn pod lớn, chứ không phải cùng một tỷ lệ thu nhỏ lại.
Nhận đúng con số trong tệp khai báo
Giá trị Gi lẻ như 1,5 hay 2,5 quy đổi gọn thành 1.536 và 2.560 MiB, nên bạn chọn được mức giới hạn nằm giữa các lũy thừa tròn của hai.
Chép được thẳng vào YAML và cờ dòng lệnh
Mỗi ô sao chép con số mộc, nên nó rơi thẳng vào limits.memory hay chuỗi JAVA_OPTS mà không có hậu tố lạc nào làm hỏng khâu phân tích cú pháp.
Chạy được từ cả hai đầu
Bắt đầu từ phía MiB khi con số lấy ra từ bảng số liệu, hoặc từ phía GiB khi nó đến từ hạn mức. Nút đảo đơn vị gắn lại nhãn cho cặp ô chỉ bằng một cú bấm.
Số liệu cụm không rời trình duyệt
Con số dung lượng cụm là thông tin nội bộ. Mọi phép tính chạy ngay trên máy bạn sau khi trang đã tải xong.
Thắc mắc quanh bộ nhớ container
Mi trong tệp khai báo Kubernetes có đúng là MiB không?
Đúng. Các hậu tố đại lượng Ki, Mi, Gi và Ti chính là đơn vị nhị phân theo IEC, nên 1Gi bằng 1.024 mebibyte. Các hậu tố không có chữ i thuộc nhóm thập phân, và cả hai dạng đều hợp lệ trong cùng một tệp — đó đúng là lý do một lỗi gõ lệch một ký tự lọt qua khâu duyệt mã.
Vì sao phải chừa khoảng thở giữa heap của JVM và giới hạn container?
Cgroup đếm từng byte tiến trình chạm tới. Ngăn xếp luồng, metaspace, bộ nhớ đệm mã JIT, cấu trúc của bộ thu gom rác và vùng đệm trực tiếp đều nằm chồng lên -Xmx. Khi tổng đó vượt giới hạn, nhân hệ điều hành giết thẳng tiến trình, không có bước suy giảm êm ái nào trước đó — nên phần dự phòng phải được tính trước, chứ đừng để phát hiện ra giữa lúc có sự cố.
-Xmx4g thực sự giữ chỗ bao nhiêu, và viết theo MiB thì thế nào?
-Xmx4g chặn heap ở 4 GiB, tức 4.096 MiB, và giống hệt -Xmx4096m. Những hậu tố này của JVM xưa nay vẫn là nhị phân, nên chuyển một giá trị qua lại giữa cờ dòng lệnh và trường Mi không cần chỉnh gì. JVM đời mới còn nhận được cả tỷ lệ phần trăm của giới hạn container mà nó tự phát hiện, đỡ phải sửa ở hai nơi mỗi lần đổi giới hạn.
Bộ nhớ đệm trang của Linux có bị tính vào giới hạn của pod không?
Các trang tệp được lưu đệm bị tính cho cgroup, nên một container đọc ghi nhiều trông sát giới hạn hơn nhiều so với những gì riêng heap gợi ý. Khi bị ép, nhân sẽ thu hồi phần đệm đó thay vì giết pod. Vậy nên lúc thấy biểu đồ theo MiB dựng đứng đáng ngại, hãy xem phần tăng là bộ nhớ ẩn danh hay chỉ là bộ nhớ đệm, rồi hãy nâng giới hạn Gi.
Có nên viết cả requests lẫn limits bộ nhớ bằng Mi không?
Giữ cả hai trong một đơn vị là thói quen thực dụng, và Mi cho phép chỉnh mịn mà không cần số lẻ. Phần requests là thứ bộ lập lịch dùng để xếp pod; phần limits là thứ nhân hệ điều hành cưỡng chế. Viết một bên bằng Gi và bên kia bằng Mi vẫn hợp lệ, nhưng khiến khoảng cách giữa chúng khó nhìn ra ngay khi soát một bản khác biệt mã.
Chưa có bình luận nào. Hãy là người đầu tiên!