MiB in GiB umrechnen

Ein Mebibyte sind 1.024 Kibibyte, also 1.048.576 Byte. Linux-Werkzeuge und Speicherangaben meinen in aller Regel das, auch wenn „MB" dasteht.

Ein Gibibyte sind 1.073.741.824 Byte, rund 7 % mehr als ein Gigabyte. Windows misst in Gibibyte, schreibt aber „GB" daran — darin besteht das ganze Rätsel des verschwundenen Speicherplatzes.

In dieser Richtung wird geteilt, und zwar durch eine ganze Zahl: 1.024 davon passen restlos in ein Gibibyte. Unangenehm ist daran nur, dass die Ergebnisse als Brüche herauskommen — ein Drittel, ein Zwölftel — statt als die runden Zahlen, die die Gegenrichtung liefert.

Verloren geht dabei trotzdem nichts, denn die Division ist exakt. Wenn dein Ergebnis als Dezimalzahl nicht stillhalten will — 0,0833… und Verwandte —, dann ist das der Bruch, der durchscheint, und kein Fehler, der sich einschleicht.

Ein MiB sind 1.024 der Einheit darunter, ein MB sind 1.000. Auf dieser Seite ist das der Unterschied zwischen 0,001 GiB und 0,0009 GiB — 4,9 % —, und der Abstand wächst mit jeder Stufe. Bei einem Foto ist er ein Rundungsfehler, bei einer Festplatte ein sichtbares Stück.

Darin besteht das Rätsel um den fehlenden Speicherplatz vollständig. Eine Platte, die als MB verkauft wird, enthält exakt das, was draufsteht; Windows teilt anschließend durch 1.024 statt durch 1.000, behält den dezimalen Namen bei und zeigt deshalb eine kleinere Zahl an. macOS rechnet seit Version 10.6 in den dezimalen Einheiten und zeigt die Zahl von der Verpackung — dieselbe Platte, zwei Rechner, zwei Größen, und verloren geht dabei nichts.

Kubernetes-Ressourcenangaben kennen zwei Suffix-Familien: die binäre — Ki, Mi, Gi, Ti — mit Zweierpotenzen zu 1.024, und die dezimale — k, m, M, G, T — mit Zehnerpotenzen. Ob ein Cluster auf Hetzner Cloud, der Open Telekom Cloud oder einem eigenen Rechenzentrum läuft, ändert daran nichts: memory: 512Mi und memory: 512M sind beide gültig, unterscheiden sich um 24.870.912 Byte, und keines der beiden erzeugt eine Warnung.

Die Lücke wächst mit jeder Stufe: 4,9 Prozent bei Mega, 7,4 Prozent bei Giga — 4Gi und 4G liegen knapp 295 Megabyte auseinander. Jedes Werkzeug in der Kette gibt exakt das weiter, was im Manifest stand, und ein Manifest-Repository einmal nach einem einzelnen Buchstaben M oder G in einem Speicherfeld zu durchsuchen, ist eine Prüfung, die sich lohnt.

CPU lässt sich drosseln — ein Container, der mehr anfordert als sein Limit, wird langsamer, läuft aber weiter. Arbeitsspeicher lässt sich nicht drosseln: Überschreitet die Cgroup eines Containers ihr Limit, beendet der OOM-Killer des Kernels einen Prozess darin, der Container meldet Exit-Code 137, und der Pod startet neu. Ein Limit, das um 4,9 Prozent zu klein geraten ist, ist damit kein Rundungsfehler, sondern eine andere Ausfallrate.

Die beiden Suffixe versagen dabei unterschiedlich: M statt Mi macht das Limit kleiner und den Container anfälliger für einen Kill — ein sichtbarer Fehler, der auffällt. Mi statt M macht es größer, was sich zunächst gar nicht bemerkbar macht, bis der Knoten überbucht ist, weil der Scheduler auf Zahlen gepackt hat, die allesamt etwas großzügiger waren als gedacht — der teurere Fehler, weil er still bleibt.

In der deutschen Java-Enterprise-Landschaft — bei Banken, Versicherern, Behörden — läuft ein erheblicher Teil der Anwendungen noch als klassische JVM in einem Container. Ein -Xmx4096m bindet einen 4-GiB-Heap, aber der tatsächliche Speicherbedarf des Prozesses liegt darüber: Metaspace ist standardmäßig unbegrenzt, jeder Thread nimmt außerhalb des Heaps typischerweise 1 MiB Stack, der Code-Cache belegt bis zu 240 MiB, und Direct Byte Buffers liegen ganz außerhalb der Heap-Buchführung.

Ein Container-Limit gleich der Heap-Größe ist deshalb ein Container, der beendet wird. Üblich ist, dem Container 25 bis 50 Prozent mehr zu geben als dem Heap zugestanden wird — oder gar kein -Xmx mehr zu setzen und stattdessen -XX:MaxRAMPercentage das Cgroup-Limit auslesen zu lassen, seit JDK 10 der Standardweg, wobei der Vorgabewert von 25 Prozent bei einem 4-Gi-Container nur einen 1-GiB-Heap ergibt, sofern er nicht angehoben wird.

Ein Knoten mit 16 GiB bietet Pods nicht 16.384 MiB an. Von der Kapazität gehen die für Kubernetes reservierten und die für das Betriebssystem reservierten Anteile sowie die harte Eviction-Schwelle ab, bevor die tatsächlich verteilbare Menge übrigbleibt — bei einem verwalteten Cluster reicht die Reservierung von wenigen hundert Mebibyte auf einem kleinen Knoten bis über ein Gibibyte auf einem großen. kubectl describe node zeigt beide Zahlen nebeneinander.

Genau hier zahlt sich das Umrechnen in Gibibyte aus, weil eine Packrechnung in Mebibyte leicht zu Fehlern einlädt: Neun Replikate zu je 1.536Mi sind 13.824Mi, also 13,5 GiB — passend in 14,6 GiB verteilbarer Kapazität mit Raum für die Daemonsets, aber nicht mehr passend, sobald die Reservierung höher ausfällt, als der erste Blick vermuten ließ.

Die Anfrage (request) ist, was der Scheduler reserviert, das Limit ist, was der Kernel durchsetzt, und das Verhältnis zwischen beiden entscheidet die Eviction-Priorität des Pods. Sind Anfrage und Limit gleich, erhält der Pod die Klasse Guaranteed; ist die Anfrage kleiner als das Limit, wird er Burstable; ist keins von beiden gesetzt, BestEffort — als Erstes verdrängt, sobald ein Knoten unter Druck gerät. Die Klasse ergibt sich aus den beiden Zahlen, sie wird nicht extra deklariert.

Bei Arbeitsspeicher ist das Argument für gleiche Werte stärker als bei CPU: Ein Burstable-Pod, der gewohnheitsmäßig mehr nutzt als angefragt, wird als klein eingeplant und als groß beendet, und der Knoten, auf dem er landet, ist überbucht, ohne dass jemand die Zahl geprüft hat. Wo der tatsächliche Bedarf bekannt ist, ist dieselbe Gibibyte-Zahl zweimal einzutragen sowohl einfacher als auch ehrlicher als eine Spanne, die niemand mehr überprüft.

Die Zahl, die es wert ist, umgerechnet zu werden, ist die tatsächlich genutzte — container_memory_working_set_bytes ist die Kennzahl, an der Kernel und OOM-Killer sich faktisch orientieren: residenter Speicher abzüglich des Seitencaches, der sich freigeben lässt. Den Spitzenwert über zwei Wochen zu nehmen, Reserve hinzuzufügen und auf eine runde Mebi- oder Gibibyte-Zahl aufzurunden, ergibt ein Limit, das sich begründen lässt; der eigene RSS-Wert des Containers oder gar der Heap-Bericht der JVM ergibt eins, das sich nicht begründen lässt.

Wo die Wahl frei ist, lohnt sich das Aufrunden auf eine Zweierpotenz: Ein Limit von 1.536Mi ist 1,5 GiB und passt sauber in nach Gibibyte bemessene Knoten; ein Limit von 1.600Mi ist 1,5625 GiB, passt schlecht und verrät dem nächsten Leser, dass die Zahl irgendwo aus einer dezimalen Rechnung stammt. Die Arithmetik ist in beiden Richtungen exakt, sodass hier nur zu gewinnen ist, wie leicht die Zahl für den nächsten zu lesen ist, der sie ändern muss.