なぜLinuxが突然「フリーズ」するのか？
Chromeのタブを30個開き、Dockerコンテナを5つ走らせ、VS Codeでコードを書く。すると突然、マウスカーソルがカクつき始め、完全にフリーズしてしまう。Fedoraをメインの開発環境として使っているなら、一度はこの状況に遭遇したことがあるでしょう。私はFedoraを2年以上使っており、パッケージの更新の速さが非常に気に入っていますが、RAMの管理は適切に設定しない限り難しい課題です。
以前、Linuxカーネルはこの問題を解決するために**OOM Killer**を使用していました。しかし、これには「実行が遅すぎる」という欠点がありました。カーネルがメモリ不足（Out of Memory）を認識したときには、システムはすでに「スラッシング（thrashing）」状態に陥っていることが多いのです。この状態ではCPUがRAMとSwap間のデータ入れ替えに忙殺され、結果としてシステムが麻痺し、操作不能になります。
systemd-oomdはこの状況を変えるために登場し、Fedora 34からデフォルトとして採用されました。メモリが完全に枯渇するのを待つのではなく、**Pressure Stall Information (PSI)** という指標を監視します。PSIは、リソース（CPU、RAM、I/O）を待つためにアプリケーションがどれだけの時間を費やしているかを示します。待ち時間が安全なしきい値を超えると、systemd-oomdはシステムがフリーズする前に先手を打って介入します。
systemd-oomdの状態を確認する
Fedoraにはこのツールがプリインストールされていますが、特にサーバー版などでは安定して動作しているか確認することをお勧めします。ターミナルを開いて以下のコマンドを実行してください：
systemctl status systemd-oomdもし active (running) という行が表示されれば、システムは保護されています。監視されているリソースグループ（cgroups）の詳細を確認するには、次のコマンドを使用します：
oomctlこのコマンドは、Control Group のリストと現在のメモリ圧迫度を表示します。systemd-oomdの大きな利点は、アプリケーションのグループ単位で管理できることです。単一のプロセスを停止させるのではなく、関連するクラスター全体を処理してRAMを徹底的に解放します。
開発者のための最適化設定
メインの設定ファイルは /etc/systemd/oomd.conf にあります。Fedoraのデフォルト設定でも十分ですが、重いタスクを頻繁に実行する場合は調整を検討してください。
sudo nano /etc/systemd/oomd.conf以下の3つの重要なパラメータに注目してください：
- SwapUsedLimitPercent: デフォルトは90%です。スワップが90%に達すると、システムがアクションを開始します。高速なNVMe SSDを使用している場合はそのままの設定で構いません。古いHDDを使用している場合は、ラグを避けるために80%まで下げると良いでしょう。
- DefaultMemoryPressureLimitPercent: メモリ圧迫の制限値（デフォルトは60%）です。アプリのせいでメモリ不足による遅延が時間の60%を超えた場合、そのアプリは「処理」対象のリストに入れられます。
- DefaultMemoryPressureDurationSec: アクションをトリガーするまでの圧迫持続時間（デフォルトは20秒）です。
編集後、サービスを再起動します：
sudo systemctl restart systemd-oomd重要なアプリケーションを保護する方法
ビデオのレンダリングや重いスクリプトの実行中に、systemd-oomdによって勝手に終了させたくない場合があります。その場合、User Sliceごとに設定を行い、制限を緩和することができます。
現在のセッションを保護するには、以下のコマンドでオーバーライドファイルを作成します：
systemctl edit user.sliceファイルに以下の内容を追加します：
[Slice]
ManagedOOMMemoryPressure=auto
ManagedOOMMemoryPressureLimit=80%制限を80%に引き上げることで、システムに害を及ぼすと見なされる前に、アプリケーションにさらなる「余裕」を与えることができます。
監視と実際のテスト
systemd-oomdがこれまでに何回システムを救ったかを知るには、システムログを確認します。今朝、なぜChromeが突然終了したのかをデバッグする際によく使う方法です：
journalctl -u systemd-oomdアプリケーションが停止された場合、ログにはっきりと表示されます：“Killed /user.slice/… due to memory pressure”。
ストレステストを行うには、以下の小さなスクリプトを使用してシステムメモリを使い果たすことができます。注意： 試す前に、すべての作業を保存してください。
# 16GBの仮想RAMパーティションを作成し、データを書き込んでメモリを枯渇させる
sudo mount -t tmpfs -o size=16G tmpfs /mnt
dd if=/dev/zero of=/mnt/test_file bs=1M count=15000正常に動作していれば、システムが重くなり始めた瞬間にsystemd-oomdが dd コマンドを停止させます。
Fedoraでの実体験に基づくアドバイス
32GB以上のRAMを搭載していても、systemd-oomdを完全に無効にしないでください。代わりに zRAM と組み合わせて使用することをお勧めします。FedoraはzRAMを使用して、ハードディスクに書き込む代わりにRAM上で直接データを圧縮します。この組み合わせにより、高負荷時でもシステムは非常に高速にレスポンスを返します。
このツールが「攻撃的すぎる」と感じる場合は、DefaultMemoryPressureDurationSec を30秒または40秒に増やしてみてください。これにより、強制的な手段を講じる前に、システムが自然にメモリを解放する時間を稼ぐことができます。
このテクニックが、Fedoraでの作業をより安定させるのに役立つことを願っています。これからは、タブを開きすぎてフリーズするたびに、電源ボタンを押して再起動する必要はもうありません。
