OSのメモリ管理の仕組み — アプリの作業場所とRAMはどう違う？

ひよこ

ブラウザーをたくさん開くと、なぜメモリが増えるの？

ペンギン先生

画像やプログラムのデータを置く作業場所が必要だからだよ。RAMには限りがあり、OSは複数のアプリへ配分している。まず、アプリが使う仮想アドレスと、実際にRAMへ置く場所を分けて見よう。

ひよこ

仮想メモリは、ディスクをRAMの代わりにすること？

ペンギン先生

それだけではないよ。アプリごとのアドレス空間を実際のメモリへ対応付け、保護や共有にも使う仕組みなんだ。スワップを使わないシステムにも仮想メモリはある。RAMを無限に増やすものでもないんだ。

ひよこ

対応はどうやって調べるの？

ペンギン先生

ページという単位で対応表を管理し、CPUのMMUが変換に使うよ。ページサイズは構成で違い、大きなページを使う場合もあるので、一律4KBではないんだ。図は位置を対応させるイメージで、実際のサイズ比ではないよ。

ひよこ

毎回、対応表を全部読むの？

ペンギン先生

TLBなどが最近の変換結果を覚えるので、毎回最初からたどる必要はないよ。見つからなければ表をたどる。ヒット率や速さはプログラムとハードウェアによって違うから、99%以上などの固定値では説明しないんだ。

ひよこ

ページフォルトって、アプリの失敗？

ペンギン先生

正常な処理でも起きるよ。まだ割り当てていないページを用意したり、コピーオンライトを処理したり、ファイルやスワップから内容を戻したりする。不正なアクセスなら拒否されることもあり、必ずディスクを読む現象ではないんだ。

ひよこ

RAMが足りなくなれば、全部スワップへ出せる？

ペンギン先生

そうとは限らないよ。ファイルのキャッシュを回収する場合も、退避できないメモリもある。スワップの有無や設定も違う。RAMとストレージの往復が増えると遅くなり得るけれど、遅さの原因はほかにも調べよう。

ひよこ

空きが少ない表示だけで、危険と判断していい？

ペンギン先生

LinuxならMemAvailableなども見るよ。キャッシュのためにRAMが使われていても、新しい処理へ回せる分がある場合がある。アプリのヒープ、プロセスのRSS、OS全体の使用量も同じ数字ではないんだ。

ひよこ

OOM Killerは、一番大きいアプリを止めるの？

ペンギン先生

単純に最大のものを選ぶとは限らないよ。LinuxのOOM選択には使用量や調整値、対象の範囲が関わる。cgroupの制限で起きる場合もある。まずログと制限を調べ、設定を無闇に変えず、どの範囲が不足したか確認しよう。

まずは、3つの「使用量」を分ける

メモリはアプリの作業場所ですが、表示される数字は同じ範囲を測っているとは限りません。アプリのヒープ、プロセスがRAMに持つページ、OS全体のRAMを分けるところから始めましょう。

Node.jsが使えるなら、新しいフォルダーにmemory-demo.jsを保存し、node memory-demo.jsを実行します。大きなメモリを埋める実験は行いません。

const usage = process.memoryUsage();
console.log("V8 heap used:", usage.heapUsed);
console.log("process RSS:", usage.rss);

どちらもバイト数で出ますが、数値は環境・実行時点で変わります。heapUsedはV8のヒープの使用量、rssはプロセスの常駐メモリの範囲です。rssにはコードやスタック等も含まれ、この2つを「アプリが使ったRAM」として同じ意味では読めません。

仮想アドレスとRAMの場所を対応させる

OSはプロセスごとの仮想アドレス空間を管理し、ページテーブルとCPUのMMUが物理メモリへの対応付けに関わります。同じ仮想アドレス値でも、別プロセスで同じデータを指すとは限りません。共有するページもあります。

ページは管理の単位です。4KBの構成はありますが、アーキテクチャや大きなページの設定で違います。TLBは変換のキャッシュで、ヒットしなければ必要なページテーブルをたどります。

ページフォルトとスワップを混同しない

ページフォルトは、CPUがそのままアクセスできずOSの処理が必要になる例外です。未割り当てのページの用意、書き込み時のコピー、ファイルやスワップからの読み込みなど、原因はさまざまです。不正なアクセスならエラーになる場合もあります。

スワップはメモリの一部を退避するための仕組みです。キャッシュの回収とスワップへの書き出しは同じ操作ではなく、すべてのページを退避できるわけでもありません。仮想メモリがあることと、スワップが有効なことは別です。

もう少し詳しく：不足の範囲と、数字の読み方

Linuxでは/proc/meminfoにMemFree、MemAvailable、Cachedなどがあります。MemAvailableはスワップせず新しいアプリに使える量の見積もりで、単なる未使用量とは違います。短い1回の測定だけでリークを決めず、同じ負荷での推移を見ます。

メモリ確保をどこまで認めるかはオーバーコミットの方針でも変わります。確保の成功は、あらゆる状況で後のアクセスを保証するものではありません。一方、「LinuxはいつもRAM+スワップ以上を無制限に許す」という説明も正しくありません。

OOMでは、OS全体なのかcgroup等の範囲なのか、ログ・使用量・設定した制限を確認します。oom_scoreには調整値なども反映され、単純な最大使用量のランキングではありません。言語側のヒープ上限で起きたエラーとも区別します。

覚え方と次の一歩

「メモリ管理」って出てきたら「アプリの作業場所を対応付け、配分・保護する仕組み」と思えばだいたいOK！

GCの仕組みでアプリ内の回収を、OSのプロセス管理で仕事の単位を確認できます。

参考資料

• Node.js：process.memoryUsage — V8のヒープ、RSSなどの測定範囲
• Linux kernel：Page Tables — MMU・TLB・ページサイズ・正常/不正なページフォルト
• Linux man-pages：proc_meminfo(5) — MemAvailableはスワップなしで使える量の見積もり
• Linux kernel：Overcommit Accounting — オーバーコミットの0/1/2の方針
• Linux man-pages：proc_pid_oom_score(5) — OOM対象選択と調整値を含むスコア