【悲報】Linuxさん、メモリ90%使い切って「 正常です」ww 空きRAMを食い尽くす設計思想がマジでど初心者を殺しにくる
Linuxを使い始めた人は皆、同じ画面で驚かされる。アプリを大して動かしていないのにメモリ使用率が90%超。「もう限界では」と思って確認すると、空きメモリはわずか200MB程度。16GB搭載マシンの98%以上が埋まっているのだ。だが、この状態が実際には正常なことがある。使用率という数字だけを見て異常と判断するのは早すぎる、というのがLinuxメモリ管理の設計思想の核心だ。
ポイントは「使われているメモリの中身」だ。Linuxは余っているRAMを使い、ファイルの読み書きを速くするための一時的なデータ、いわゆるページキャッシュとして活用する。キャッシュとは、後から消しても問題ないデータのこと。元のファイルがディスクに残っているなら、RAM上のコピーを捨てられるため、完全な空き領域が少なくても実際には余裕がある場合がある。
この設計に明確な理由がある。ディスクのアクセス時間はRAMの数千〜数万倍遅く、ファイルを読むたびにSSDへアクセスしていたら待ち時間が積み重なる。一度読んだファイルの内容をRAMに置いておけば、同じデータが再度必要になったときにディスクに行かずに済む。さらにDRAMは内容を維持するために定期的なリフレッシュ動作を必要とするため、RAMを開けたままにしても電力面で大きな利益があるとは限らない。「余っているRAMは無駄」という思想は、単なるメモリ大量消費ではなく、合理性に基づいた判断なのだ。
見るべきは「mem free」でなく「mem available」
Linuxのメモリ余裕を測るなら、memfreeよりmemavailableが重要だ。memfreeは完全に未使用のRAMだけを測る指標。だが新しいアプリが使えるのはその空き領域だけではない。回収可能なキャッシュも含めた「スワップを使わずに新しい処理へ割り当てられる容量」がmemavailableだ。たとえばmemfreeが約200MBでも、memavailableが8GB以上あるケースがある。この場合、見た目ほどメモリが逼迫していない。
回収の仕組みも進化している。Linuxカーネル6.1以降で導入される改良版のリクレイマー（MGLRU）は、ページを世代で分け、古い世代を回収候補にする方式。回収したページが直後に再び必要になったかどうかも評価し、重要なデータを誤って回収する問題を減らす。回収処理のCPU負荷も下がり、メモリ節約とCPU節約を両立できる。ただし6.1以降でも全環境で有効とは限らず、カーネルの設定やディストリビューションによって実際の動作は変わる。
それでも足りなくなると「OOM Killer」が呼ばれる
回収できるメモリが不足すると、プログラムが突然強制終了することがある。これがOOM Killerだ。OOMはメモリ不足を意味する。「キャッシュを捨てればいいのに」と思いがちだが、キャッシュと表示されるデータが全て捨て可能とは限らない。たとえばtmpfsに置かれたファイルや共有メモリは、通常のファイルキャッシュと違って元のディスク上のファイルがないため、勝手に破棄できず、退避できない状況ではメモリを圧迫する。
設定も動作に影響する。スワップを使わない設定、すなわちvm.swappinessをゼロにするのは一見安全に見えるが、MGLRUが有効な環境では効果が薄いことがある。特別な回収が行われず、スワップが残っていてもOOMになる場合があるのだ。さらにはコンテナに設定されたメモリ上限に達した場合もOOMが発生しうる。ホストマシンのRAM全体に余裕があっても、そのコンテナ内では使えない。全体の空き容量だけでは判断できない。
そしてOOM Killerは状況に応じて終了させるプロセスを選び、メモリを確保しようとする。普段は効率的でも限界を超えれば厳しい判断が必要になるのが現実だ。大切なプログラムが選ばれる可能性もあるため、対策が必要になる。
Windowsも同じをしていたという事実と、二重キャッシュ問題
実は、空いたRAMをキャッシュに使うのはLinuxだけではない。Windowsも同じように余ったメモリを積極的に活用している。ただし、分類方法と画面上の表示が違うため「メモリを使っていないように見える」だけだ。Windowsにはスタンバイリストと呼ばれるキャッシュ領域があり、これを再利用可能な容量として扱う事前読み込みの仕組み「SysMain」もある。Windowsが空きRAMを遊ばせているという理解は正しくない。
ただし、メモリ不足への対応はOSごとに違う。Linuxは設定によってメモリのオーバーコミットを許容し、後でOOMが発生しうる設計。一方Windowsはコミット制限によって割り当て要求を事前に拒否する仕組みを重視する。どちらが単純に優秀という話ではなく、設計上の選択が違う。
便利さと裏腹なのが、データベースで発生する「二重バッファリング」の問題だ。多くのDBは自前のバッファを持ち、通常のファイル入出力ではLinuxのページキャッシュも使われる。その結果、同じデータが別々の領域に保持される。対策の一つがダイレクトI/Oという方式で、ページキャッシュを経由しない入出力により、アプリ側でキャッシュ管理を完結できる。ただし入出力の制約や性能特性を考慮する必要があり、すべてのDBで一律に採用するのは難しい。有名なDB開発者たちもダイレクトI/Oへの強い批判を残している。
ネットの反応
なんとなくbtop眺めてましたが理解が深まりました。ありがとうございます。
スワップの使用率を設定で減らしてzramでメモリを圧縮してます。
Macも同じような感じですよね。
Windowsも積極的に余剰メモリを使ってほしい。Linux入れたら96GBのメモリをどんどん使ってくれてありがてえ。Windows11は32GBしか使ってくれないという。
AIの所感
この解説が優れているのは、「使用率90%は異常か」の答えを「正常でも異常もあり得る」と誤魔化さず、判定の軸をmemfreeからmemavailableへと明確に移し替えたことだ。数字の大きさではなく、何に使われているかが本質であるという視点は、監視ツールの閾値設定だけに頼る運用者にとって一つの抑止になる。加えて、Linuxは不足時に強制終了で対処するがWindowsは事前に拒否する設計という対比が、単なるOS間の争いではなく「後出し回収型」と「事前制限型」という相反する設計方針として整理されている。
取り分け、vm.swappinessをゼロにする「祈祷的設定」が万能ではないという実挙も重要だ。OOMはコンテナの上限など、全体の空き容量は関係しない局地戦で発生しうる。メモリ不足を検知したら、単純にRAMの増設に走るより、tmpfsの利用量やコンテナの上限など、何が空けられずにRAMを占有しているのかを特定する道筋が現実的な判断として必要になっている。（2026年10月20日時点の情報）