MiB naar GiB omrekenen

Een mebibyte is 1.024 kibibyte, oftewel 1.048.576 bytes. De hulpmiddelen van Linux en de geheugengetallen bedoelen vrijwel altijd dit, ook als er «MB» staat.

Een gibibyte is 1.073.741.824 bytes, ongeveer 7 % meer dan een gigabyte. Windows meet in gibibytes maar noemt ze «GB», en daarin zit het hele raadsel van de verdwenen ruimte.

Deze kant op is het een deling, en wel door een heel getal: er gaan er 1.024 in één gibibyte, zonder rest. Het enige lastige is dat de uitkomsten in breuken vallen — een derde, een twaalfde — in plaats van de ronde getallen die de andere richting geeft.

Er gaat toch niets verloren, want de deling is exact. Wil je uitkomst als decimaal niet stil blijven staan — 0,0833… en familie —, dan is dat de breuk die doorschemert, geen fout die binnensluipt.

Eén MiB is 1.024 van de eenheid eronder; één MB is 1.000. Op deze pagina is dat het verschil tussen 0,001 GiB en 0,0009 GiB — 4,9 % — en het gat groeit bij elke stap omhoog: op een foto een verwaarloosbare afronding, op een harde schijf een zichtbaar stuk.

Hierin zit het raadsel van de verdwenen opslag volledig. Een schijf die als terabyte verkocht wordt bevat in decimale eenheden precies wat erop staat; Windows telt hem daarna in binaire eenheden maar houdt de decimale naam aan, en daar krimpt het getal zonder dat er iets weg is. macOS telt deze eenheden sinds 10.6 decimaal, en daarom kan dezelfde schijf op twee computers twee maten lijken.

Kubernetes-resourcehoeveelheden accepteren twee families achtervoegsels. De binaire set — Ki, Mi, Gi, Ti, Pi, Ei — vermenigvuldigt met machten van 1.024. De decimale set — m, k, M, G, T, P, E, met een kleine letter kilo — vermenigvuldigt met machten van 1.000, en de m vooraan is een milli die bestaat voor fractionele CPU in plaats van voor geheugen. memory: 512Mi en memory: 512M zijn beide geldig, verschillen 24.870.912 bytes, en produceren in geen van beide gevallen een waarschuwing.

De kloof van 4,9 procent bij de mebibyte-stap verbreedt naar 7,4 procent bij de gibibyte-stap: 4Gi is 4.294.967.296 bytes en 4G is 4.000.000.000. Elk gereedschap in de keten bewaart trouw wat er ook geschreven werd, en de waarde in een dashboard is meestal geherformatteerd naar welke eenheid dat dashboard verkiest, dus is het originele achtervoegsel alleen zichtbaar in het manifest zelf. Een repository doorzoeken op een kale M of G in een geheugenveld is een vijf-minuten-audit die eenmalig de moeite waard is.

CPU is comprimeerbaar: een container die meer vraagt dan zijn limiet wordt vertraagd en gaat langzaam door. Geheugen niet. Overschrijdt een cgroup van een container zijn geheugenlimiet, dan beëindigt de OOM-killer van de kernel een proces erin, meldt de container exitcode 137, en herstart de pod. Er is geen geleidelijke degradatie en geen waarschuwing ertussen, wat waarom een limiet die 4,9 procent kleiner is dan bedoeld geen afrondingsfout is maar een verandering in hoe vaak een workload sterft.

Het betekent ook dat de twee achtervoegsels asymmetrisch falen. M schrijven waar Mi bedoeld was, maakt de limiet kleiner en de container waarschijnlijker gedood — een zichtbare fout die onderzocht wordt. Mi schrijven waar M bedoeld was, maakt hem groter, wat helemaal niet zichtbaar wordt tot de node overcommitted is en de scheduler cijfers heeft ingepakt die allemaal een beetje royaal waren. De tweede is degene die stilletjes geld kost.

Een JVM gestart met -Xmx4096m heeft een heap van 4 GiB en een merkbaar grotere totale voetafdruk. Metaspace bevat class-metadata en is standaard onbegrensd; elke thread neemt zijn stack, doorgaans 1 MiB, buiten de heap; de code cache van de JIT is standaard 240 MiB op 64-bit HotSpot; directe bytebuffers gebruikt door Netty en de meeste NIO-gebaseerde servers zijn native geheugen; en de garbage collector houdt zijn eigen structuren bij. Een containerlimiet gelijk aan -Xmx is een container die gedood zal worden.

De gangbare praktijk is de container 25 tot 50 procent meer te geven dan de heap, of -Xmx helemaal niet te zetten en de JVM zichzelf te laten dimensioneren. Sinds JDK 10 leest de runtime de cgroup-limiet en past -XX:MaxRAMPercentage toe, standaard 25 — voorzichtig genoeg dat een container van 4Gi een heap van 1 GiB krijgt tenzij het percentage verhoogd wordt. Het op 70 of 75 zetten en de JVM de rekenkunde laten doen, verwijdert een van de twee getallen die fout kunnen zijn.

Een node geadverteerd als 16 GiB biedt geen 16.384 MiB aan pods. Capaciteit min kube-reserved min system-reserved min de harde evictiedrempel geeft allocatable, en op een beheerd cluster loopt die reservering typisch van een paar honderd mebibyte op een kleine node tot ruim een gibibyte op een grote. kubectl describe node drukt capacity en allocatable naast elkaar af, en het verschil is het getal dat bepaalt hoeveel replica’s daadwerkelijk passen.

Hier verdient omzetten naar gibibytes zich terug, want bin-packing-rekenkunde in mebibytes nodigt fouten uit. Negen replica’s op 1.536Mi is 13.824Mi, wat 13,5 GiB is, wat past binnen 14,6 GiB allocatable met ruimte voor de daemonsets en niet past als de node meer reserveert dan het leek. Dezelfde som in mebibytes doen en vergelijken met een node opgegeven in gibibytes is hoe een cluster één pod tekortkomt zonder duidelijke oorzaak.

De request is wat de scheduler reserveert en de limit is wat de kernel afdwingt, en de relatie ertussen bepaalt de evictieprioriteit van de pod. Gelijke request en limit geeft Guaranteed; een request lager dan de limit geeft Burstable; geen van beide gezet geeft BestEffort, wat als eerste geëvicteerd wordt bij nodedruk. De klasse volgt uit de twee getallen in plaats van gedeclareerd te worden, dus heeft een manifest dat 512Mi en 1Gi zet Burstable gekozen, of iemand het nu bedoelde of niet.

Voor geheugen specifiek is het argument om ze gelijk te zetten sterker dan voor CPU. Een Burstable-pod die gewoonlijk meer gebruikt dan zijn request wordt gepland alsof hij klein is en gedood alsof hij groot is, en de node waar hij op landt is overcommitted op basis van een cijfer dat niemand controleerde. Waar de werkset bekend is, is hetzelfde gibibyte-cijfer tweemaal schrijven zowel eenvoudiger als eerlijker dan een spreiding die niemand herbekijkt.

Het manifest zegt 1536Mi; Grafana zegt 1,5 GiB; de cloudconsole zegt 1,61 GB; het kostenrapport zegt 1,6 GB-uur. Alle vier zijn dezelfde 1.610.612.736 bytes, gepresenteerd door vier gereedschappen met verschillende conventies, en alleen de eerste twee staan aan de binaire kant. Een rekening reconciliëren tegen een manifest betekent weten aan welke kant elk cijfer staat voor je vergelijkt, en de kloof van 7,4 procent is groot genoeg dat een mismatch als een echte discrepantie oogt.

De gewoonte die helpt, is één canonieke eenheid per document te houden. Capaciteitsplannen in gibibytes, manifesten in Mi of Gi, welke het cijfer heel houdt, en elk cijfer opgegeven in een decimale eenheid als zodanig gelabeld. Een capaciteitsspreadsheet met een kolomkop GiB en getallen uit een console die GB rapporteert, klopt niet en blijft niet kloppen tot iemand hem herbouwt.

Het cijfer dat de moeite waard is om om te zetten, is degene die de workload daadwerkelijk gebruikt, en container_memory_working_set_bytes is de metriek waarop de kernel en de OOM-killer effectief handelen — resident geheugen min de page cache die reclaimbaar is. De piek ervan over veertien dagen nemen, marge toevoegen, en afronden naar een net gibibyte- of mebibyte-cijfer levert een limiet op die te verdedigen is; de RSS van de container nemen, of erger, het heap-rapport van de JVM, levert een op die dat niet is.

Rond naar boven af naar een macht van twee waar de keuze vrij is. Een limiet van 1.536Mi is 1,5 GiB en past netjes in nodes gedimensioneerd in gibibytes; een limiet van 1.600Mi is 1,5625 GiB, past slecht, en vertelt de volgende lezer dat het getal ergens uit een decimale berekening kwam. De rekenkunde is in beide richtingen exact, dus wordt alleen geoptimaliseerd hoe leesbaar het getal is voor wie het als volgende moet veranderen.