Menentukan Batas Memori Kontainer dalam MiB
Jatah kapasitas diserahkan kepada Anda dalam gibibyte: sebuah node mengiklankan 16 Gi memori yang bisa dialokasikan, kuota namespace memberi satu tim 64 Gi. Namun kolom yang Anda isi — resources.limits.memory di manifes pod, atau angka setelah -Xmx — hampir selalu ditulis dalam mebibyte. Mengubah jatah Gi menjadi angka Mi itu adalah aritmetika pertama di setiap sesi penyetelan heap, sekaligus yang paling sering dikira-kira.
MiB = GiB × 1024. Alokasi 6 GiB berarti 6 × 1024 = 6144 MiB, jadi baris manifesnya berbunyi limits.memory: 6144Mi. Bagi dengan 1024 untuk kembali.Mi Bukan M
Mi berarti mebibyte (1.048.576 byte) sedangkan M polos berarti megabyte. Mengetik 512M padahal maksud Anda 512Mi diam-diam memangkas alokasi sebesar 23,72 MiB, dan tidak ada peringatan apa pun.-Xmx Memakai Basis yang Sama
m dan g pada JVM juga biner, sehingga -Xmx4g dan -Xmx4096m meminta heap yang sama besar. Itu menjadikan ×1024 sebagai bahasa bersama antara manifes dan argumen JVM.Heap Bukan Seluruh Kontainer
-Xmx. Setel heap sama besar dengan batasnya, maka cgroup menyentuh langit-langitnya sebelum pengumpul sampah merasakan tekanan sedikit pun.Mengubah Jatah Gi Menjadi Angka Heap
Masukkan Angka Gi
Ketik angka gibibyte dari kuota atau deskripsi node Anda ke kolom kiri. Pecahan tidak masalah — 1,5 dan 1.5 sama-sama terbaca, dan spasi diabaikan.
Salin Angka MiB Telanjang
Tombol Salin menaruh deretan angka di papan klip tanpa satuan menempel — persis yang pantas berada di depan Mi pada YAML atau di belakang -Xmx pada argumen JVM.
Sisihkan Cadangan Non-Heap
Potong sebagian dari total MiB itu untuk segala sesuatu di luar heap. Seperempat dari batas adalah cadangan awal yang lazim bagi layanan JVM, lalu diperketat kemudian berdasarkan grafik pemakaian.
Periksa Pod Berjalan dari Arah Sebaliknya
Dasbor melaporkan memori working set dalam MiB. Tekan Tukar satuan untuk membalik arah dan membaca angka MiB langsung sebagai gibibyte terhadap kapasitas node yang dijanjikan kepada Anda.
Kedua kolom tetap bisa disunting, jadi mengetik di sisi MiB langsung mengonversi balik ke GiB tanpa langkah tambahan. Tiap sisi juga membawa daftar satuan yang bisa dicari, berguna ketika laporan biaya menyebut alokasi yang sama dalam satuan lain.
Batas Kontainer dan Nilai Heap Berdampingan
Inilah batas-batas yang paling sering muncul pada penggelaran nyata, sudah dikonversi ke mebibyte dan dipecah menjadi jatah heap dan cadangan non-heap dengan pembagian 75/25. Kolom cadangan adalah ruang lega yang menjauhkan sebuah pod dari daftar OOMKilled.
| Batas kontainer | Batas yang sama dalam MiB | Heap pada 75% | Cadangan non-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 |
Kontainer kecillah yang paling terasa digigit rasio ini. Pada 512 MiB cadangannya hanya 128 MiB, dan metaspace ditambah beberapa lusin tumpukan thread bisa melahap sebagian besarnya — itulah sebabnya pod Java mungil butuh persentase heap yang lebih rendah daripada yang besar, bukan persentase sama yang diperkecil.
Membaca Angka Manifes Apa Adanya
Nilai Gi pecahan seperti 1,5 atau 2,5 dikonversi rapi menjadi 1.536 dan 2.560 MiB, jadi Anda bisa memilih batas di antara kelipatan dua yang bulat.
Siap Tempel ke YAML dan Argumen
Tiap kolom menyalin angka polos, jadi hasilnya masuk ke limits.memory atau untai JAVA_OPTS tanpa akhiran nyasar yang merusak penguraiannya.
Berfungsi dari Kedua Ujung
Mulailah dari sisi MiB bila angkanya berasal dari panel metrik, atau dari sisi GiB bila berasal dari kuota. Tukar satuan menukar label pasangan itu dalam sekali klik.
Tidak Ada yang Keluar dari Peramban
Angka penentuan ukuran klaster adalah informasi internal. Semuanya dihitung di mesin Anda sendiri begitu halaman selesai dimuat.
Pertanyaan Seputar Memori Kontainer
Apakah Mi di manifes Kubernetes sama artinya dengan MiB?
Ya. Akhiran kuantitas Ki, Mi, Gi, dan Ti adalah satuan biner IEC, jadi 1Gi sama dengan 1.024 mebibyte. Akhiran tanpa huruf i termasuk kelompok desimal, dan kedua bentuk itu sah dalam berkas yang sama — persis alasan salah ketik satu karakter bisa lolos dari peninjauan.
Kenapa harus menyisakan jarak antara heap JVM dan batas kontainer?
Cgroup menghitung setiap byte yang disentuh proses. Tumpukan thread, metaspace, cache kode JIT, struktur pengumpul sampah, dan buffer langsung semuanya bertengger di atas -Xmx. Begitu totalnya melewati batas, kernel langsung mematikan prosesnya tanpa penurunan mutu bertahap lebih dulu — jadi cadangan itu harus direncanakan, bukan ditemukan saat insiden berlangsung.
Sebenarnya -Xmx4g memesan berapa, dan bagaimana menulisnya dalam MiB?
-Xmx4g membatasi heap pada 4 GiB, yaitu 4.096 MiB dan identik dengan -Xmx4096m. Akhiran itu memang selalu biner di JVM, jadi tidak perlu penyesuaian apa pun saat memindahkan nilai antara sebuah argumen dan kolom Mi. JVM modern juga bisa menerima persentase dari batas kontainer yang terdeteksi, sehingga Anda hemat satu suntingan di dua tempat setiap kali batasnya berubah.
Apakah cache halaman Linux ikut dihitung ke batas memori pod saya?
Halaman berkas yang di-cache dibebankan ke cgroup, jadi kontainer yang banyak membaca atau menulis tampak jauh lebih dekat ke batasnya daripada yang disiratkan heap saja. Kernel akan menarik kembali cache itu saat tertekan, bukan mematikan pod karenanya. Ketika grafik dalam MiB terlihat mengkhawatirkan, periksa dulu apakah pertumbuhannya memori anonim atau sekadar cache sebelum menaikkan batas Gi.
Apakah requests dan limits memori sebaiknya sama-sama ditulis dalam Mi?
Menyatukan keduanya dalam satu satuan adalah kebiasaan yang praktis, dan Mi memberi kendali halus tanpa pecahan. Requests dipakai penjadwal untuk menempatkan pod; limits adalah yang ditegakkan kernel. Menulis yang satu dalam Gi dan yang lain dalam Mi memang sah, tetapi membuat jarak di antara keduanya sulit dinilai sekilas di dalam sebuah diff.
Belum ada komentar. Jadilah yang pertama berkomentar!