Sizing a Container Memory Limit in MiB
Capacity gets handed to you in gibibytes: a node advertises 16 Gi of allocatable memory, a namespace quota grants a team 64 Gi. But the field you fill in — resources.limits.memory in a pod manifest, or the number after -Xmx — is nearly always written in mebibytes. Turning the Gi allowance into that Mi figure is the first arithmetic of every heap-tuning session, and the one most often fudged.
MiB = GiB × 1024. A 6 GiB allocation is 6 × 1024 = 6144 MiB, so the manifest line reads limits.memory: 6144Mi. Divide by 1024 to go back.Mi Is Not M
Mi is a mebibyte (1,048,576 bytes) while a bare M is a megabyte. Typing 512M where you meant 512Mi silently shrinks the allocation by 23.72 MiB, and nothing warns you.-Xmx Speaks the Same Base
m and g suffixes are binary too, so -Xmx4g and -Xmx4096m request the same heap. That makes ×1024 the shared language between manifest and JVM flags.The Heap Is Not the Container
-Xmx. Set the heap equal to the limit and the cgroup hits its ceiling before the collector feels any pressure.Turning a Gi Allowance Into a Heap Number
Enter the Gi Figure
Type the gibibyte number from your quota or node description into the left field. Fractions are fine — 1.5 and 1,5 both work, and spaces are ignored.
Copy the Bare MiB Number
The copy button puts the digits on the clipboard with no unit attached — exactly what belongs in front of Mi in YAML or after -Xmx in a JVM argument.
Carve Out the Native Reserve
Take a slice off that MiB total for everything outside the heap. A quarter of the limit is a common opening reserve for a JVM service, tightened later from usage graphs.
Check a Running Pod in Reverse
Dashboards report working-set memory in MiB. Press swap to flip the direction and read a live MiB figure back as gibibytes against the node capacity you were promised.
Both fields stay editable, so typing into the MiB side converts back to GiB with no extra step. Each side also carries a searchable unit list, useful when a cost report quotes the same allocation in something else.
Container Limits and Heap Values Side by Side
These are the limits that show up most often in real deployments, converted to mebibytes and split into a heap allowance and a non-heap reserve at 75/25. The reserve column is the headroom that keeps a pod out of the OOMKilled list.
| Container limit | Same limit in MiB | Heap at 75% | Non-heap reserve |
|---|---|---|---|
| 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 |
Small containers are where the ratio bites hardest. At 512 MiB the reserve is only 128 MiB, and metaspace plus a few dozen thread stacks can eat most of it — which is why tiny Java pods need a lower heap percentage than large ones, not the same one scaled down.
Reads Manifest Numbers As-Is
Fractional Gi values such as 1.5 or 2.5 convert cleanly to 1,536 and 2,560 MiB, so you can pick a limit between the round powers of two.
Clipboard-Ready for YAML and Flags
Each field copies the unadorned number, so it drops into limits.memory or a JAVA_OPTS string without a stray suffix breaking the parse.
Works From Either End
Start on the MiB side when the number came off a metrics panel, or on the GiB side when it came off a quota. Swap relabels the pair in one click.
Nothing Leaves the Browser
Cluster sizing figures are internal information. Everything is computed on your own machine once the page has loaded.
Container Memory Questions
Does Mi in a Kubernetes manifest mean the same thing as MiB?
Yes. The quantity suffixes Ki, Mi, Gi and Ti are the IEC binary units, so 1Gi is 1,024 mebibytes. The suffixes without the i belong to the decimal set, and both forms are legal in the same file — which is exactly why a one-character typo slips through review.
Why leave headroom between the JVM heap and the container limit?
The cgroup counts every byte the process touches. Thread stacks, metaspace, the JIT code cache, collector structures and direct buffers all sit on top of -Xmx. When that total crosses the limit the kernel kills the process outright, with no graceful degradation first — so the reserve has to be planned, not discovered during an incident.
What does -Xmx4g actually reserve, and how do I write it in MiB?
-Xmx4g caps the heap at 4 GiB, which is 4,096 MiB and identical to -Xmx4096m. Those suffixes have always been binary in the JVM, so no adjustment is needed moving a value between a flag and an Mi field. Modern JVMs can also take a percentage of the detected container limit instead, saving an edit in two places whenever the limit changes.
Does the Linux page cache count against my pod's memory limit?
Cached file pages are charged to the cgroup, so a container that reads or writes heavily looks far closer to its limit than the heap alone suggests. The kernel reclaims that cache under pressure rather than killing the pod for it. When a graph in MiB looks alarming, check whether the growth is anonymous memory or just cache before raising the Gi limit.
Should memory requests and limits both be written in Mi?
Keeping both in one unit is the practical habit, and Mi gives fine control without decimals. The request is what the scheduler uses to place the pod; the limit is what the kernel enforces. Writing one in Gi and the other in Mi is valid, but it makes the gap between them hard to judge at a glance in a diff.
No comments yet. Be the first to comment!