GiB を kB に変換

1 ギビバイトは 1,073,741,824 バイトで、ギガバイトより 7 % ほど大きい値です。Windows はギビバイトで測りながら、それを「GB」と表示します。「容量が足りない気がする」という疑問のからくりは、まるごとこれです。

1 キロバイトは、標準化団体が定義すれば 1,000 バイトで、OS が定義すれば 1,024 バイトです。このページは 1,000 で計算します。1,024 のほうはキビバイトという名前を持っています。

倍率は 1073741.824 で、これをそのまま持ち歩く人はまずいません。1070000 に丸めると 0.35 % ずれます。小さい数では見えもしませんが、1,000 GiB あたりで、ずれは丸ごと 1 単位になります。

丸める前に知っておく価値があるのは、ずれの大きさそのものではなく、それを無視できなくなる地点のほうです。それより下なら短い倍率が賢明で、それより上なら上の入力欄を使ってください。あちらは書き出す前に丸めません。

GiB 1 つはひとつ下の単位の 1,024 倍で、GB 1 つは 1,000 倍です。このページでは 1073741.824 kB と 1000000 kB の差——7.4 %——になり、段を上がるごとにこの隔たりは開いていきます。写真 1 枚では丸め誤差でしかないものが、ハードディスクでは目に見える割合になるのはそのためです。

「容量が消えた」という話の中身は、これだけです。GB で売られたディスクには、書いてあるとおりのバイト数が入っています。それを 1,000 ではなく 1,024 で割り、名前は GB のまま表示しているのが Windows です。macOS は 10.6 以降ディスクの容量を十進の単位で数えているので、同じディスクが 2 台のパソコンで違う大きさに見えることがあります。減ったものはなく、丸めているのでもありません。同じバイト数に、名前が 2 つあるだけです。

すべての Linux ホストの /proc/meminfo は値に "kB" という接尾辞を付けて出力しますが、そのすべてがキビバイトです。このラベルは IEC の名称が生まれるより何年も前から存在し、今それを変更すればこのファイルを読んできたあらゆるパーサー、エージェント、スクリプトが壊れます。ですから、このプラットフォームでもっとも参照されるメモリー値の出どころは、恒久的に一つの単位を使いながら別の単位を名乗っています。

これが問題になるのは、今どき /proc/meminfo を直接読むものがほとんど存在しないからです。エクスポーター、エージェント、コンテナランタイムがこれを読み、スケーリングし、ダッシュボードへ渡し、各層が受け取った数字を 10 進法と見るか 2 進法と見るかをそれぞれ独自に判断します。グラフに表示されるメモリーの数字は、たいてい誰かが見る前にラベルの間違った単位を一度通過しています。誤りがあるとすれば、それはパネルより上流で入り込んだものです。

監視画面がメモリーやディスクをギビバイトで表示するのは、その桁でこそ数字が読みやすいからです。それらの数字と比較される対象は、しばしばずっと小さく、人が書いたものです。1 リクエストあたり 200 kB のメモリー予算、平均 40 kB のオブジェクトサイズ、キャッシュエントリのコスト、他チームの容量文書に載った数字などです。人が書いた数字はほぼ例外なく 10 進法です。

ですからこの比較は、100 万倍という桁の差と、7.37 パーセントという単位体系の差の両方を越えなければならず、たいていはインシデント対応中に誰かの頭の中で越えられます。それは計算をするには最悪のタイミングであり、だからこそ一度だけ変換し、その結果を単位付きで書き留めて、切迫した状況で再導出するのではなく Runbook に置いておく価値があります。

Grafana の単位一覧には SI のバイトと IEC のバイトの両方があり、選択はパネルごとに行われます。前者を選べば 8,589,934,592 バイトは 8.59 GB と表示され、後者を選べば 8 GiB と表示されます。どちらも同じ測定値で、どちらも正直にラベル付けされていますが、そのラベルは小さく、差は 7.37 パーセントあり、二つのダッシュボードを見比べる誰もまずパネル設定を確認しません。

これが問題になるのは、別々の時期に別々の人が組み立てたパネルからダッシュボードが構成されている場合です。一つはホストのメモリーを GiB で、隣のパネルはコンテナの上限を GB で示し、二つは並んで直接比較できるように見えます。一致すべき二つの数字がいつも約 7 パーセントずれているなら、最初に調べるべきはパネルの単位設定で、確認はクリック一つで済みます。

Prometheus のエクスポーターや現代的なエージェントの多くは、生のバイト数を報告します。node_memory_MemAvailable_bytes は目盛りの付いていないバイト数であり、名前がそう告げています。これは正しい設計です。メトリクスは測定値を運び、表示層が見せ方を担うので、あいまいさは人間が書式を選んだ場所にしか入り込めません。

これはまた、どんな不一致にも解決策があるということでもあります。同じシステムの二つのビューが食い違っていたら、下層のメトリクスに問い合わせてバイト数どうしを比較してください。バイト数は単位を間違えようがありません。メモリー使用率が報告より 7.4 パーセント高いかどうかをめぐる議論の大半は、ここで、30 秒ほどで、誰も事前に正しくある必要なく決着します。

「メモリー使用率が 85 パーセントを超えたら」というアラートは、あるバイト数を別のバイト数で割っており、単位は約分されて消えます。表示の慣習で壊れることはなく、ホストがリサイズされても生き延び、変換もまったく要りません。有用なアラートの大半が比率として書かれるのはそのためで、単位変換についてのこのページが、それをごまかさずに述べておく価値があります。

それでも絶対的なしきい値には出番があります。コンテナに設定されたメモリー上限に一致しなければならない制限、割合ではなく空き容量そのものが重要なディスクの数字、契約で合意された割り当てなどです。それらはアラート定義の中でバイトで書き、表示のためだけに書式を整えてください。8 GB とタイプされたしきい値が、8 GiB に設定された上限に対して使われれば、6.87 パーセント低く設定されたことになり、そのルールが存在する限り毎回早めに発火します。

free は既定でキビバイト単位で報告し、より大きな 2 進法の単位には -m、-g、-h を用意しています。ps と top は常駐セットサイズをキビバイトで示します。vmstat は 1,024 バイトのブロックを使います。slabtop はキビバイトで数えます。これらを合わせると、エンジニアがメモリー問題を診断する際に見るものの大半をカバーしており、そのどれも「i」を書きません。

この一貫性はせめてもの助けになります。Linux ホスト上で単位の明記がない小さなメモリー数値は、ほぼ確実にキビバイトであってキロバイトではなく、1,024 を掛ければバイトに達します。落とし穴はプラットフォームの内側ではなく境界にあり、クラウドコンソールやベンダー文書、仕様書から来た数字は本物の 10 進法のキロバイトであることがあり、他のものとまったく同じに見えます。

監視スタックから外に出た数字は、それを解釈可能にしていた文脈を失います。チケットやレポート、事後報告書の中の「プロセスは 1.4 GB を使用していた」は、読む人によって 1.4 GiB とも 1.4 GB とも解釈され、その規模では 100 メガバイトの差になり、上限を超えたかどうかの議論では十分に意味を持つ差です。

バイト数を併記することがもっとも安上がりな防御策で、この規模なら追加の一文で済みます。「1.4 GiB、つまり 1,503,239 kB」。これで変換も慣習も議論も一行で消え、1 年後にインシデント記録を読み返したときにも意味の通る、あらゆる測定値に共通する規律です。

コンテナのメモリー上限と現在の使用量は、どちらも cgroup ファイルシステムの中に単純なバイトの整数として存在します。cgroup v2 では memory.max と memory.current です。そこでは何もスケーリングされず、ラベルも付かず、丸められてもいません。ダッシュボードがコンテナについて示すすべての数字は、これらのファイルのどちらかから読み取られ、それより上のどこかで書式が整えられています。単位の選択はその層で行われています。

これはコンテナのメモリーをめぐるあらゆる不一致を決着させる確実な方法を与えてくれます。ファイルを読み、整数を比較すれば、上限が 4 GB か 4 GiB かは解釈の問題ではなくなります。4,294,967,296 は片方で、4,000,000,000 はもう片方であり、ファイルがどちらかを教えてくれます。これはファイルのプロパティダイアログで正確なバイト数を読むのと同じ原理を、もう一段下の層で、プロセスが終了させられるかどうかを決める数字に適用したものです。