GiB を MiB に変換

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

1 メビバイトは 1,024 キビバイト、つまり 1,048,576 バイトです。Linux のツールとメモリーの数値は、表示が「MB」であってもほぼ常にこちらを指しています。

こちら向きの計算は掛け算で、しかも整数です。ギビバイト 1 つはちょうど 1,024 メビバイト。この 1,024 は近い値に落ち着いた測定値ではなく、定義です。

だからこれは、暗算する価値のある数少ない計算のひとつです。検算もできます。割り戻せば、始めた数にきっかり戻るはずです。余地はいっさい残りません。

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

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

QEMU の -m はそのままのメビバイト数です。virt-install も --memory をメビバイトで受け取ります。多くのクラウドやハイパーバイザーの API は IEC 接頭辞ができる前から memoryMB というフィールド名を使っていて、値はラベルに関わらず2進法です。一方でインスタンスカタログや容量計画、調達文書はどれもギビバイトで書かれているので、変換はまさにサイズが決断から設定へ変わる瞬間に起きます。

libvirt は例外で知っておく価値があります。ドメイン XML の memory 要素は既定でキビバイトを使うからです。8GiBのゲストは <memory unit='KiB'>8388608</memory> になり、誤植に見える値がむしろ別の単位であることがよくあります。この要素は明示的な unit 属性を受け付けるので、人が編集するテンプレートに unit='GiB' と書いておけば、この疑問は永久に消えます。

8,192MiBを割り当てられたゲストは、ゲスト自身のページ分に加えて、仮想マシンだからこそ存在する一群の構造の分もホストのコストになります。ネストしたページテーブルはゲストの物理アドレス空間をホストの物理アドレスに対応づけ、ゲストのアドレス空間が広がるにつれて大きくなります。デバイスモデルはホストのプロセスとして独自のヒープを持って動きます。エミュレートされたビデオメモリーも実際に確保される領域です。ハイパーバイザーは割り当てるすべてのページについて、ページごとの管理情報を保持します。

合計はたいてい固定の数字ではなく小さな割合で、これが8GiBのゲストを8台快適に動かせていたホストが、算数が同じでも16GiBのゲストを4台動かせるとは限らない理由です。割り当てたメビバイトの合計を単に足して搭載メモリーと比べるサイジングは、ハイパーバイザー自身の分を何も残しておらず、その先で起きる失敗はホストのスワップです。それはゲストにとって最初からメモリーを少なく割り当てられるよりずっと悪いことです。

ゲストのメモリーは一般に初回の書き込み時に確保されるので、16,384MiBを割り当てられたばかりのゲストがホスト側で消費しているのは、そのおよそ十分の一のこともあります。バルーンドライバーはハイパーバイザーがさらに回収できるようにする仕組みで、ゲストの内部で膨らみ、ゲストのカーネルがそれを満たすためにページを解放し、ハイパーバイザーがそれを回収します。しぼませば戻ります。割り当ての数字は確保ではなく上限になります。

容量計算にとっての結論は、ゲストごとに3つの数字があり、そのうち設定ファイルに書かれているのは1つだけだということです。割り当ては入力した値、風船の目標は現在ハイパーバイザーが許可している値、常駐は実際にホストが確保している値です。この3つのうちどれか1つをギビバイトで表示するダッシュボードが、別の1つに基づいて立てた計画と比べられると、1日のうちに変わる係数だけずれます。

ゲストをヒュージページで裏付けるとページテーブルの参照が1段減り、メモリー負荷の高いワークロードでは測定できるほどの効果がありますが、算数は変わります。ページは4KiBではなく2MiBになるので、割り当ては2MiBの倍数でなければならず、プールはホスト側にあらかじめ確保されていて他の用途には使えなくなり、遅延確保は止まります。ヒュージページで裏付けられたゲストは割り当て分をすぐに全部消費するからです。

これによって8,192MiBは上限から4,096枚のヒュージページの確約に変わり、そのゲストではオーバーコミットがオフになります。ホストのプールも同じ単位でサイジングする必要があります。65,536枚のヒュージページを確保することは128GiBを確保することであり、ゲストが使う以上にプールを確保したホストは、その分をほかのすべてから取り上げてしまいます。ゲストが1GiBのヒュージページを使う場合は、割り当ては1,024MiBの倍数でなければならず、間違いの粒度は丸ごと1ギビバイトになります。

複数のメモリーノードを持つホストでは、1つのノードより大きいゲストを分割する必要があり、その分割はスケジューラーに任せるより意図的に行うほうがずっと良い結果になります。12,288MiBのゲストを2ノードに分けると各ノード6,144でこざっぱりしています。同じゲストを12,000MiBにすると各ノード6,000で、算数としては問題ありませんが、ヒュージページやノードごとの予約に対しては扱いにくくなります。

これを暗黙のままにしたときの失敗はリモートメモリーアクセスです。1つのノードに固定された仮想 CPU がもう一方のノードにあるページを読むと、アクセスごとにレイテンシーの代償を払い、その結果は小さいホストで動かした同じゲストより遅くなることです。virsh numatune とゲスト自身の NUMA トポロジーはどちらも重要で、どちらもノードごとのメビバイトで設定されるので、その前にギビバイトの数字がきれいに割れる必要があります。

割り当てたメビバイトの合計をホストのメモリーで割ればオーバーコミット比率が得られ、アイドルなゲストが混ざるワークロードでは1.5程度までの比率が日常的です。それがうまくいくのは、割り当てが上限であり、多くのゲストがそこに近づかないからです。うまくいかないのは、その上限に近づくゲストがたいてい同時にそうなることです。同じ出来事に反応しているからです。

比率と一緒に追いかけておく数字は平均ではなくピーク時のホストの空きメモリーで、避けるべきなのはホストがスワップに手を伸ばすことです。ページがホストによってスワップアウトされたゲストは、それを何の説明もなく千倍遅くなったメモリーとして経験し、そのページを RAM だと信じているゲスト自身のメモリー管理は、まさに間違った判断を下すことになります。