CPUもディスクも異常がないのにサーバー全体が重く、原因が見つからずに落ち着いて調べ直そうとしている一人運用の保守担当者
障害対応・運用監視約11分

「サーバー、なんか重いんですけど」と言われて見に行く。でも top を叩いても、CPU使用率はそこまで高くない。ディスクも空いている。エラーログも静か。なのに、ls を打つだけでワンテンポ遅れる。管理画面を開くと、いつもなら一瞬なのに数秒待たされる——。「原因が見当たらないのに、確かに遅い」。この気持ち悪さ、けっこう消耗しますよね。

そんなとき、静かに足を引っ張っていることがあるのがスワップです。しかもスワップは、「使われているかどうか」だけを見ても判断を誤りやすい、ちょっとクセのある指標です。この記事では、その見分け方を一緒に順番に整理していきます。

結論：見るのは「swapの残量」ではなく「いま出し入れしているか」

先にお伝えします。スワップを疑うときに見るのは、次の3つです。

  1. free -h の Swap used：どれくらいスワップに退避されているか（＝過去の痕跡）。
  2. vmstat 1 の si / so：いま毎秒どれだけ出し入れしているか（＝現在進行形の負荷）。これがいちばん大事です。
  3. メモリの余裕（free -h の available）：そもそも空きが枯れているのか。

ポイントはひとつだけ覚えてください。「swap が使われている」ことと「swap が原因で遅い」ことは、別の話です。

Swap used が数百MBあっても、si/so がずっと 0 なら、それは「昔ヒマなときに、使われていないデータを倉庫に片づけた」だけ。悪さはしていません。逆に、Swap used がそれほど大きくなくても、si/so が毎秒動き続けているなら、メモリとディスクの間で荷物を往復させ続けている状態で、サーバー全体が遅くなります。

そもそもスワップって何をしているの？

スワップ（swap）は、メモリが足りなくなったときに、当面使わないデータをディスクへ一時的に退避させる仕組みです。ディスク上のスワップ領域（パーティションやファイル）が、メモリの「臨時の物置」として使われます。

ここで大事なのが速度差です。メモリとディスクでは、読み書きの速さが桁違いに違います。SSDでもメモリよりずっと遅く、HDDならさらに差が開きます。つまり、

この「往復し続けている」状態を、俗にスラッシングと呼びます。CPU使用率としては wa（I/O待ち）に出たり、そもそも数字に出にくかったりするので、「CPUは高くないのに全部遅い」という、あの気持ち悪い症状になるわけです。

メモリからディスクのスワップ領域へデータが退避されるだけの状態と、メモリとスワップの間を往復し続けて遅くなる状態を比べた図
「片づけるだけ」なら問題なし。「出しては戻す」を繰り返し始めると、サーバー全体が遅くなる

手順1：free -h で全体像をつかむ

まずは今の状態を見ます。

free -h

見るのは2か所です。

available が全体に対してごくわずかしか残っていないなら、メモリが逼迫しています。逆に available に十分な余裕があるのに Swap used だけそこそこある場合は、前に混んだ時間帯があって、その名残が残っているだけというケースがよくあります。スワップは、戻す必要が出るまで自動では戻ってこないためです。

なお、スワップ領域そのものがあるか・どこかは次で確認できます。

swapon --show

何も表示されなければ、そのサーバーにはスワップがありません（その場合、メモリ不足はスワップではなく OOM として現れます）。

手順2：vmstat 1 で「いま動いているか」を確かめる

ここが本命です。

vmstat 1 10

1秒ごとに10回、状況を出してくれます。注目するのは swap 欄の2つです。

判断はシンプルです。

同じ画面の wa（CPUのI/O待ち）も一緒に上がっていれば、「みんなディスクの応答を待って行列している」という裏づけになります。ロードアベレージだけ高くて CPU使用率が低いときの正体も、しばしばこれです。

補足：vmstat は1行目が「起動してからの平均」なので、2行目以降を見てください。1行目だけを見て判断すると、過去の平均に引っぱられます。

手順3：どのプロセスがスワップを使っているか探す

スワップが動いていると分かったら、次は「誰が食っているか」です。各プロセスのスワップ使用量は /proc/<PID>/status の VmSwap に出ています。まとめて見るなら、たとえばこうです。

for p in /proc/[0-9]*; do
  s=$(awk '/^VmSwap/{print $2}' $p/status 2>/dev/null)
  n=$(awk '/^Name/{print $2}' $p/status 2>/dev/null)
  [ -n "$s" ] && [ "$s" -gt 0 ] && echo "$s KB  $n  $p"
done | sort -rn | head -20

上位に出てきたものが、スワップに退避されている量の多いプロセスです。よく顔を出すのは、

あたりです。top を開いて Shift + M（メモリ順ソート）で RES の大きい順に見るのも、合わせ技として有効です。

ここで一緒に確認したいのが、時間帯との対応です。「毎晩2時ごろだけ重い」なら、その時間に走っているバッチやバックアップと重なっていないか。cron の一覧と見比べるだけで、原因が一気に絞れることがあります。

手順4：一次対処は「減らす」から。焦って swapoff しない

原因の見当がついたら、対処です。安全な順に並べます。

1. 一時的な負荷なら、まず収まるのを確認する バッチや一時的なアクセス集中が原因で、すでに si/so が落ち着いてきているなら、あわてて何かする必要はありません。Swap used の数字が残っていても、それ自体は害ではありません。

2. メモリを多く使っている設定を見直す 再発しているなら、ここが本丸です。よくある効きどころは、

「同時に走る数 × 1プロセスあたりの使用量」が、実メモリに収まっているか。この掛け算がメモリ設計のいちばん基本です。設定を変えるときは、必ず変更前の値をメモして、少しずつ動かしてください。

3. 該当プロセスを再起動して様子を見る（暫定） メモリの使用量がじわじわ増えていくタイプ（リーク）なら、対象サービスの再起動でいったん戻ります。ただしこれは暫定対応です。再発の間隔を記録しておくと、恒久対応の材料になります。

4. swapoff は慎重に 「スワップを切れば速くなるのでは」と思いたくなりますが、swapoff はスワップ上のデータを全部メモリへ戻す動作です。メモリに余裕がない状態でやると、その瞬間に OOM でプロセスが落ちる可能性があります。実行するなら、free -h の available が Swap used を十分上回っていることを確認してからにしてください。急いでいるときほど、ここは踏みとどまる場面です。

5. vm.swappiness の調整は「効くこともある」程度に vm.swappiness は、カーネルがどれくらい積極的にスワップを使うかの傾向値です（多くのディストリビューションで既定は 60）。値を下げるとスワップに出しにくくはなりますが、メモリが足りないという事実そのものは変わりません。順番としては、まず使用量を減らす（手順2）。swappiness はそのあとの微調整、と考えておくと安全です。設定を変える場合も、いきなり恒久化せず、検証環境と一時反映で挙動を確かめてからにしてください。

明日やること：平常時の si / so を1行メモしておく

スワップがいちばん役に立つのは、実は障害のときより「ふだんの状態を知っているとき」です。

明日、気になっているサーバーで一度だけ、次を確認してみてください。

free -h
vmstat 1 5

そして、「平常時は Swap used がこれくらいで、si/so はほぼ 0」という1行を運用メモに残しておく。これだけで、次に「なんか重い」と言われたとき、vmstat を1回叩けば「いつもと違うかどうか」が即答できるようになります。監視を入れているなら、swap使用量そのものより、swap in/out のレートをグラフに出しておくと、より早く気づけます。

チェックリスト：サーバーが重くてスワップを疑うとき

よければ、こちらも

スワップは、「メモリが足りなくなってきた」という静かなサインでもあります。同じ“重い・遅い”をたどる手順や、その先の OOM の見方も合わせて型にしておくと、落ち着いて対処できます。

原因がスワップだと突き止められて、サーバーの重さの正体が分かり肩の力が抜けている保守運用の担当者

「原因が見当たらないのに遅い」は、調べている側がいちばん消耗する状況です。でも、free と vmstat を1回ずつ叩いて si/so を見る——この一手を持っておくだけで、その正体不明の重さが「メモリが足りていない」という具体的な話に変わります。

今日はまず、気になっているサーバーで vmstat 1 5 を一度だけ叩いて、平常値を1行メモするところから始めれば十分です。ふだんを知っている人が、いちばん早く異常に気づけます。原因が名前のあるものに変わった時点で、もう対応は前に進んでいます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語