そういう状態でとりあえず再起動してその場をしのいでいると、ある日突然サービスが止まる。Linuxサーバーのメモリ不足はじわじわと進行することが多く、気づいた時にはすでに重要なプロセスが強制終了されていた、という典型的なパターンで障害につながりやすい。
この記事では、RHEL 9系～10系・Ubuntu 24.04 LTSを想定環境として、Linuxサーバーのメモリが不足したとき何が起きるのかをOOMキラー（Out of Memory Killer）とスワップの仕組みから解説する。freeコマンドによるメモリ確認・スワップファイルの追加・swappinessの調整まで、実務で使える手順と考え方をまとめる。
この記事のポイント
・OOMキラーはメモリ枯渇時にカーネルが自動発動しプロセスを強制終了する仕組みだ
・メモリ確認はfree -hのfree列ではなくavailable列を見ること
・スワップ大量使用はメモリ不足のシグナル。増設より前にfuserやpsで原因を特定する
・重要サービスはOOMScoreAdjust=-1000でOOMキラーの対象から除外できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
メモリが足りなくなると「何が起きるか」を理解していない人が多い
Linuxサーバーのメモリ管理でよくあるつまずきの一つが、「重くなったらとりあえず再起動する」というパターンだ。再起動すれば一時的にメモリが解放されて回復するため、問題が解決したように見えてしまう。しかし根本原因を把握しないまま運用を続けると、同じことが繰り返される。メモリが枯渇した時、Linuxカーネルは自動的にOOMキラー（Out of Memory Killer）を発動させる。OOMキラーはシステム全体を守るためにメモリ消費量が大きいプロセスを強制終了する仕組みだ。データベースやWebサーバーのような重要なサービスが突然止まる場合、OOMキラーが原因であることが多い。
「なぜサービスが急に止まったか分からない」という状況の典型パターンがこれだ。OOMキラーが動いたかどうかはdmesgやjournalctlのログに記録される。まず以下のコマンドでOOMキラーが動いていないか確認する。
# journalctlでOOMキラーの発動ログを確認する # journalctl -k | grep -i oom # dmesgでも同様に確認できる # dmesg | grep -i "oom\|killed process"
kernel: Out of memory: Kill process 4821 (mysqld) score 243 or sacrifice child
kernel: Killed process 4821 (mysqld) total-vm:2543232kB, anon-rss:512340kB
上記のようなログが残っていれば、mysqldのプロセスがOOMキラーに強制終了された証拠だ。これを「サーバーの不具合」と判断してmysqldの設定だけ調べ続けても根本原因には辿り着けない。重要なサービスが突然止まったときは、まずこのOOMキラーのログを確認するのが定石だ。
なお、OOMキラーはカーネルが独自のスコアリングアルゴリズムでどのプロセスを終了するかを決める。スコアは各プロセスのメモリ使用量・実行時間・優先度を元に計算されるため、必ずしも「最もメモリを使っているプロセス」が止まるわけではない。この予測しにくさが、OOMキラーによる障害を診断しづらくしている一因だ。
freeコマンドでメモリの現状を正確に把握する
メモリ不足を疑ったら、最初にfreeコマンドで現在の使用量を確認する。freeコマンドの出力を正確に読めるかどうかで、次のアクションが大きく変わる。1. free -hでメモリとスワップの使用量を確認する
freeコマンドに-hオプション（human-readable）を付けると、GB・MBの単位で表示され見やすくなる。# メモリとスワップの現在の使用量を確認する # free -h # 5秒おきにリフレッシュして継続監視する # watch -n 5 free -h
total used free shared buff/cache available
Mem: 15Gi 12Gi 512Mi 256Mi 2.8Gi 2.3Gi
Swap: 2.0Gi 1.8Gi 256Mi
ここで注目すべきはfree列よりavailable列だ。Linuxはメモリを効率よく使うために、空きメモリをbuff/cache（バッファとキャッシュ）として積極的に活用する設計になっている。available列はこのbuff/cacheのうち解放できる分を含めた「実際にアプリが使えるメモリ量」を示している。
上の例では、free列が512Miだからといってメモリがひっ迫しているわけではない。available列の2.3Giが実際に使える量だ。この違いを知らないと、buff/cacheが大きいだけなのに「メモリが足りない」と誤判断してしまう。初心者がよくやってしまうつまずきの一つだ。
一方でSwap行を見ると、2.0GiのスワップのうちUsedが1.8Giとほぼ満杯に近い。これは物理メモリがすでに枯渇してスワップ領域（ディスク上の仮想メモリ）を大量に使っているシグナルで、放置するとOOMキラーが発動しやすい状態だ。
2. vmstatでリアルタイムのスワッピング状況を確認する
スワップの出し入れ（スワッピング）がリアルタイムで発生しているかどうかはvmstatコマンドで確認できる。# 2秒間隔で10回サンプリングしてスワッピング状況を確認する # vmstat 2 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 1 1843200 524288 65536 2883584 420 1250 850 1300 480 220 45 8 10 37 0
si列（swap in：ディスクからメモリへの読み込み量）とso列（swap out：メモリからディスクへの追い出し量）がゼロ以外の値を継続的に示している場合は、スワッピングが頻繁に発生している証拠だ。wa（I/O待ち）の値が高い場合もこれが原因のことが多い。スワップはディスクへの読み書きを伴うため、物理メモリと比べて桁違いに遅く、サーバーのレスポンス悪化の直接原因になる。
スワップの仕組みと応急処置としての追加方法
スワップ（swap）とはディスク上に確保した「仮想的なメモリ領域」のことだ。物理メモリが枯渇した際に、使用頻度の低いメモリページをスワップ領域に追い出すことで物理メモリに空きを作る仕組みになっている。本番サーバーのメモリスペックが足りない場合の応急処置として、スワップファイルを追加することができる。3. スワップファイルを追加する手順
# 2GBのスワップファイルを作成する（RHEL 9・Ubuntu 24.04 共通手順） # fallocate -l 2G /swapfile # パーミッションをroot専用（600）に変更する（注意: 必ず600にすること） # chmod 600 /swapfile # スワップ領域として初期化する # mkswap /swapfile # スワップを有効化する # swapon /swapfile # スワップの状況を確認する # swapon --show
NAME TYPE SIZE USED PRIO
/swapfile file 2048M 256.0M -2
再起動後も有効にするには/etc/fstabに追記する。
# /etc/fstabにスワップファイルを登録する（再起動後も有効） # echo '/swapfile none swap sw 0 0' >> /etc/fstab # 追記内容の確認 # tail -1 /etc/fstab
4. swappinessでスワップ使用の積極度を調整する
vm.swappinessはLinuxがスワップをどれだけ積極的に使うかを0～100で制御するカーネルパラメータだ。デフォルト値は60。サーバー用途では物理メモリを優先して使いたいため、10前後に下げることが多い。# 現在のswappiness値を確認する # cat /proc/sys/vm/swappiness # swappinessを一時的に変更する（再起動で元に戻る） # sysctl vm.swappiness=10 # 恒久的な変更は/etc/sysctl.d/以下に設定ファイルを作る # echo 'vm.swappiness=10' > /etc/sysctl.d/99-swappiness.conf # sysctl -p /etc/sysctl.d/99-swappiness.conf
エラー・トラブル：OOMキラーが発動してプロセスが止まった時の対処
5. 発動ログを確認してどのプロセスが止まったかを特定する
OOMキラーが発動した後、最初にやることはログで「どのプロセスが強制終了されたか」を確認することだ。# systemdのジャーナルログでOOM関連を確認する # journalctl -k --no-pager | grep -i "oom\|kill" # 直近のカーネルメッセージをリアルタイムで確認する # dmesg -w | grep -i oom # Apacheが再起動しているか確認する（HTTPDを例に） # systemctl status httpd
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled)
Active: active (running) since Wed 2026-10-21 07:32:15 JST; 2min 31s ago
プロセスが止まってすぐにsystemdが自動再起動した場合は「起動時刻が最近」のことがある。起動時刻が想定より新しければ再起動が発生した可能性が高い。
6. 重要なサービスをOOMキラーから守る設定
OOMキラーはどのプロセスを終了するかをoom_scoreというスコアで決める（0～1000の範囲で高いほど終了されやすい）。重要なサービスのoom_score_adjを-1000に設定すると、OOMキラーの対象から除外できる。# プロセスのOOMスコアを確認する（PIDは実際のプロセスIDに置き換える） # cat /proc/PID/oom_score # systemdで管理しているサービスのOOMScoreAdjustを設定する # systemctl set-property httpd.service OOMScoreAdjust=-1000 # 設定を反映する # systemctl daemon-reload # 設定後に確認する # systemctl show httpd.service | grep OOMScoreAdjust
7. Cannot allocate memoryエラーへの対処
メモリが枯渇した状態でコマンドを実行しようとすると「-bash: fork: Cannot allocate memory」のエラーが発生することがある。新しいプロセスを起動するためのメモリがシステムに残っていない状態だ。このエラーが出たらfreeコマンドとdmesgを確認し、OOMキラーが発動していないかを調べるのが最初のステップだ。応急処置としてはpsコマンドで不要なプロセスを探して終了し、物理メモリに空きを作ることを優先する。# メモリ使用量が多いプロセスをRSS（実メモリ使用量）順に表示する # ps aux --sort=-%mem | head -15 # 特定プロセスのメモリ使用量の時系列変化を5秒おきに監視する # watch -n 5 'ps -p PID -o pid,rss,vsz,%mem,comm'
現役講師が語る「メモリ管理を後回しにしていた人」に多い3つのパターン
3,100名以上を指導してきた経験から、Linuxのメモリ管理を後回しにしていた人がつまずく典型的なパターンを整理する。実際に現場で繰り返されるパターンなので、思い当たることがあれば早めに対処することをすすめる。パターン1：free列とavailable列を混同してメモリ不足を誤判断する
Linuxはパフォーマンスのためにメモリをbuff/cacheとして積極的に使う設計になっている。そのため「free列が小さい＝メモリ不足」と勘違いして不要なプロセスを終了させたり、スワップを増やしたりする対処をしてしまうケースがある。見るべきはavailable列だ。availableが物理メモリ総量の10%を切り始めたあたりから、監視を強化する運用が実務では基本になる。
パターン2：スワップを増やすことで問題が解決すると思い込む
スワップはあくまで「メモリ枯渇時の緊急避難所」であり、スワップを増やしても根本的なメモリ不足は解決しない。スワップが大量に使われている状態は、物理メモリが枯渇しているシグナルだ。本来の対処は物理メモリの増設か、不要なプロセスの整理になる。スワップを増やすことでOOMキラーの発動を先送りにする効果はあるが、スワップを大量に使っている期間はサーバーのI/O負荷が高まりレスポンスが低下し続ける。
パターン3：再起動で解決したと思い込み、原因を記録しない
再起動でメモリはリセットされて一時的に回復する。しかし原因が特定のプロセスのメモリリークである場合、稼働時間が長くなるにつれて同じ状態に戻る。再起動で解決する前に、dmesgやfree -hの出力を記録しておく習慣を持つと、次回の障害対応がずっと楽になる。「再起動してしまうと証拠が消える」と意識するだけで、運用の質が変わってくる。
まとめ
Linuxのメモリ管理でよくあるつまずきと対処方法を一覧で整理する。| 確認・操作したいこと | コマンド・方法 | ポイント |
|---|---|---|
| メモリ使用量の確認 | free -h |
free列でなくavailable列を見る |
| スワッピングの発生確認 | vmstat 2 10 |
si・so列がゼロ以外なら要対処 |
| OOMキラーのログ確認 | dmesg | grep -i oom |
プロセス強制終了時に記録される |
| スワップファイルの追加 | fallocate -l 2G /swapfile && mkswap /swapfile |
chmod 600の設定を忘れずに |
| スワップ積極度の調整 | sysctl vm.swappiness=10 |
サーバー用途では10前後が推奨 |
| メモリ使用量の多いプロセス確認 | ps aux --sort=-%mem | head -15 |
RSS値が増え続けるならメモリリークを疑う |
| OOMキラーから重要サービスを保護 | systemctl set-property httpd.service OOMScoreAdjust=-1000 |
本当に守りたいサービス1～2個に絞る |
次に読む記事:
・Linuxのポート確認コマンド（ss・lsof）の使い方
・chkconfigとsystemctlの使い方と違い
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
メモリ管理・プロセス監視・ネットワーク設定まで、20年以上の現場経験を持つ現役サーバー管理者が2日間ハンズオンで指導するLinux Master Pro Seminarの詳細はこちらからご覧ください。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます