Linuxのスワップ領域(swap)とは｜確認・推奨サイズ・vm.swappinessの設定を実コマンドで解説

Linuxのスワップ領域（swap）は、物理メモリ（RAM）が足りなくなったときに、使用頻度の低いメモリの中身を一時的にディスクへ退避させる仕組みです。この記事では、いま使われているスワップを確認するコマンド、RAM容量ごとの推奨サイズ、スワップファイルの作り方、そしてスワップの使い方を左右する vm.swappiness の推奨値までを、標準的なコマンド付きで整理します。AWS EC2やKubernetes、データベースといったクラウド・コンテナ環境での運用方針も、単体サーバーとは別基準で最後にまとめます。

まとめ：Linuxスワップ運用の要点

結論を先に示します。スワップは「足りないRAMの代わり」ではなく「枯渇時の安全弁」です。

• 役割：RAM不足分をディスクで肩代わりする退避先。RAMより大幅に遅いため常用しない。
• 確認：全体は free -h と swapon --show、推移は vmstat 1 のsi/so列。
• サイズ：RHELのガイドライン（RAM 8GB超〜64GBなら最低4GB）を起点に、ワークロードで調整。
• vm.swappiness：デフォルト60、カーネル5.8以降は0〜200。メモリに余裕のあるサーバーやDBでは1〜10へ下げるのが定石。
• 例外：AWS EC2は既定でスワップ無し、Kubernetesは長く無効化が前提。クラウド/コンテナは別基準で判断。

以降の各見出しで、必要なコマンドと判断基準を順に示します。まず出発点になるのは現状把握で、次にサイズと追加方法、そしてカーネルの挙動を決める設定へと進みます。

スワップ領域（swap）とは｜RAM不足時にディスクへ退避する仮想メモリ

スワップ領域とは、ディスク上に確保した退避用の領域で、RAMが逼迫したときにカーネルが使用頻度の低いページ（メモリの管理単位）をここへ書き出します。この退避処理をスワップアウトと呼び、呼び戻しはスワップインです。どのページを追い出すかは、長く参照されていないものから外すLRU（Least Recently Used）に基づいて決まります。

RAMが「机の上」だとすれば、スワップは「引き出し」です。机に載りきらない書類を引き出しへ一時的にしまうことで作業は止まりませんが、引き出しの出し入れには時間がかかります。スワップはディスクI/Oを伴うため、ナノ秒オーダーのRAMアクセスに対しミリ秒オーダーと数万倍遅く、頻発するとシステム全体の応答が落ちます。これがスワップの本質的な制約です。

退避の対象になりやすいのは、プログラムが確保した匿名ページ（ファイルに裏付けられていないメモリ）です。一方で、ディスク上のファイルを読み込んだページキャッシュは、必要になれば再読み込みできるため、スワップとは別枠で回収されます。vm.swappiness が効くのは主に前者の匿名ページで、この区別を押さえておくと後述の設定の意味が理解しやすくなります。

そのため、スワップは「RAMを増やさずに済ませる手段」ではありません。常時スワップが発生している状態は、RAM不足かメモリの使い方に問題があるサインです。スワップはあくまで突発的な枯渇でプロセスが強制終了（OOM Kill）するのを防ぐ保険として設計し、恒常的な不足はRAM増設で解くのが基本方針になります。

Linuxでスワップ使用状況を確認するコマンド｜free・swapon・vmstat

スワップ運用の出発点は現状把握です。最頻の検索意図もここにあります。全体量はfree、領域ごとの内訳はswaponと /proc/swaps、時間推移はvmstatで確認します。3つを役割で使い分けるのがコツです。

free・swaponでスワップの全体量と使用量・優先度を確認する

free -h はメモリとスワップの合計・使用・空きを人が読みやすい単位で表示します。Swap行のusedが増え続けるなら、メモリ不足が進行しているサインです。

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       4.1Gi       1.2Gi       0.2Gi       2.5Gi       3.3Gi
Swap:          2.0Gi       512Mi       1.5Gi

$ swapon --show
NAME       TYPE  SIZE USED PRIO
/swapfile  file    2G 512M   -2

swapon --show は有効なスワップ領域を一覧し、種別（partition／file）・サイズ・使用量・優先度（PRIO）を返します。複数のスワップを併用しているとき、どれがどれだけ使われているかを把握できます。PRIOは大きいほど先に使われ、同じ値なら負荷が分散される仕組みです。/proc/swaps を直接読んでも同じ情報が得られます。

vmstatでスワップイン/アウトの発生推移を継続的に監視する

瞬間値ではなく傾向を見るにはvmstatが向きます。vmstat 1 は1秒ごとに統計を更新し、swap欄の si（スワップイン）と so（スワップアウト）が継続的に非ゼロなら、実害のあるスワップが起きていると判断できます。

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 2541960 113616 1119300  0    0     7     7   21   23  0  0 100  0  0

使用量がゼロでないこと自体は問題ではありません。判断材料はsi/soの「発生し続けているか」です。空き容量があるのにso（書き出し）が止まらない場合は、後述の vm.swappiness を見直します。長時間の傾向を後から振り返るなら、sar -W で過去のスワップ発生率を確認する方法もあります。

プロセス別のスワップ使用量を調べる方法｜smem・VmSwapで特定

スワップを押し上げている犯人を特定するには、プロセス単位の使用量を見ます。free/vmstatでは「誰が」までは分かりません。

個別プロセスの退避量は /proc/[pid]/status のVmSwap行で確認できます。多い順に並べたいときは、プロセスごとのスワップ量を表示できる smem が簡潔です（多くのディストリビューションでパッケージ追加が必要）。

# 特定プロセスのスワップ使用量
$ grep VmSwap /proc/1234/status
VmSwap:    10240 kB

# スワップ使用量が多い順にプロセスを一覧（smem）
$ smem -rs swap -c "pid name swap" | head

topでもスワップ列を表示できますが、topのSWAP値は仮想メモリのうちRAMに載っていない分の概算で、実際の退避量とは一致しないことがあります。正確なプロセス別の退避量はVmSwapまたはsmemを基準にしてください。犯人を特定したら、そのプロセスのメモリ設定見直し、再起動、あるいはRAM増設へ進みます。

スワップサイズの推奨値｜RAM容量別のRHEL公式ガイドライン

「RAMの2倍」という古い目安は、RAMが数百MB〜数GBだった時代の名残です。RAMが潤沢な現在は、Red Hat Enterprise Linux 9のガイドラインのように、RAM容量に応じて逓減させる考え方が実態に合います。ハイバネート（休止状態）を使うかどうかで必要量が変わる点に注意してください。

表のとおり、64GB超のサーバーでハイバネートを使わないなら、スワップは4GB程度で足ります。Red Hatも、推奨スワップ量はもはやRAMサイズではなくワークロードの関数だと明言しています。つまり「RAMが多いから大きなスワップ」ではなく、「そのシステムがどれだけ瞬間的なメモリ超過を起こすか」で決めるのが正しい立て方です。サイズに迷う場合は、まずこの表の値で始め、vmstatのso発生状況を見て調整します。ハイバネートを使う場合は、RAM全体をディスクへ書き出すため、少なくともRAM相当量のスワップが要る点も忘れないでください。

スワップ領域を追加・拡張する手順｜ファイル・パーティション・LVM

スワップの追加方法は3通りあり、柔軟性とパフォーマンスのトレードオフで選びます。加えて、圧縮スワップという第4の選択肢も押さえておきます。

スワップファイルの作成手順（fallocate→mkswap→swapon）

もっとも手軽なのがスワップファイルです。ファイルとして作るため、後からサイズを変えやすく、クラウドや開発環境に向きます。2GiBの例を示します。

# 2GiBのファイルを作成し権限を絞る
$ sudo fallocate -l 2G /swapfile
$ sudo chmod 600 /swapfile

# スワップとしてフォーマットし有効化
$ sudo mkswap /swapfile
$ sudo swapon /swapfile

# 再起動後も有効にする（/etc/fstab に追記）
/swapfile none swap sw 0 0

有効化後は swapon --show で反映を確認します。/etc/fstab への追記を忘れると再起動で消えるため、永続化までを1セットとして実施してください。なお、Btrfsのようにファイルの物理配置が動くファイルシステムでは、スワップファイル作成に追加の手順が要る場合があるため、ext4／xfsなど標準的な構成で作るのが無難です。

スワップパーティション・LVMとの違いと選び方・使い分け基準

専用パーティションは性能が安定し、I/Oが集中する物理サーバー向きですが、後からの拡張が面倒です。LVM（論理ボリュームマネージャ）は拡張・縮小が容易で、複数ディスクにまたがる大規模構成に向きます。判断基準を整理します。

現代の用途ではスワップファイルで困る場面はほとんどありません。ファイルシステム経由のわずかなオーバーヘッドより、サイズ変更の容易さが効くためです。確実な性能と固定運用が要る物理サーバーのみ、パーティションやLVMを検討します。

zram・zswapで圧縮スワップを使う第4の選択肢とその判断

ディスクへ書き出さず、メモリ上で圧縮して退避量を稼ぐ手もあります。zramはRAMの一部を圧縮ブロックデバイスにしてスワップ先に使う方式で、ディスクI/Oを伴わないぶん高速です。Fedoraでは既定で有効になっており、メモリの限られた小型インスタンスやエッジ機器で効果を出します。zswapはディスクスワップの前段に圧縮キャッシュを挟む方式で、実ディスクへの書き出しを減らす仕組みです。どちらもCPUで圧縮する引き換えにI/Oを抑える発想で、RAMに多少の余裕があり、かつディスクが遅い環境で選択肢になります。

vm.swappinessの設定と推奨値｜0・1・10・60とカーネル5.8以降

vm.swappiness は、カーネルがどれだけ積極的にスワップを使うかを決めるパラメータです。値が小さいほどRAMを優先し、大きいほど早めにスワップを使います。デフォルトは60です（カーネル6.x系でも既定値は60のままです）。

気をつけたいのが取り得る範囲の変更です。カーネル5.8より前は0〜100でしたが、5.8以降は0〜200に拡張され、100超でより積極的にスワップを使えるようになりました。さらに5.8以降は値0の意味も変わり、「他に手段が無いときだけ匿名ページをスワップする」挙動になっています。古い記事の「0でスワップ完全無効」という説明は、現行カーネルには当てはまりません。

# 現在値の確認
$ cat /proc/sys/vm/swappiness
60

# 一時的に変更（再起動で戻る）
$ sudo sysctl -w vm.swappiness=10

# 永続化（/etc/sysctl.d/99-swappiness.conf を作成）
vm.swappiness = 10

推奨値は用途で決めます。RAMに余裕があるサーバーやデータベースでは10前後に下げ、スワップ発生を抑えるのが一般的です。デスクトップやメモリが逼迫しがちな小型インスタンスでは、60のままか、OOMを避けるためむしろ据え置きが無難です。よく見る「10にすべき」という助言は万能ではなく、空きRAMが少ない環境で下げすぎるとOOM Killのリスクが上がります。メモリに余裕がある前提でのみ下げる、と条件を付けて運用してください。完全にスワップを止めたい特殊なケースでも、0ではなく後述のswapoffで明示的に無効化する方が挙動を読みやすくなります。

クラウド・コンテナ環境のスワップ運用｜EC2・Kubernetes・DB

ここまでは単体サーバーの話でしたが、クラウドとコンテナでは前提が変わります。競合記事が手薄な領域なので、実務の判断軸を示します。

AWS EC2にスワップが標準で無い理由と追加する際の判断基準

AWSのEC2（Amazon Linux等のAMI）は、多くのインスタンスで既定でスワップを持ちません。EBSはボリュームサイズで課金され、スワップのI/OがEBSの読み書きコストと性能消費に直結するためです。t2.microのような小容量インスタンスではメモリ不足でプロセスが落ちることがあり、その場合は前述の手順でスワップファイルを追加します。ただしこれは応急処置です。本番でスワップに頼り始めたら、インスタンスサイズの引き上げやアーキテクチャの見直しを優先してください。クラウド基盤の設計や移行を含めて相談したい場合は、AWS・Google Cloud・Azureのインフラ構築（AWS・Google Cloud・Azure）で構成の適正化から支援しています。

Kubernetesでスワップを無効化してきた背景と現状の対応

Kubernetesは長らくスワップを無効化する運用が標準で、kubeletは既定でスワップ有効なノードを拒否してきました。メモリ制限（cgroup）の挙動が読みにくくなるためです。その後ノードのスワップ利用はv1.22でアルファ、v1.28でベータへ昇格しました（cgroup v2前提）が、本番採用は慎重に判断し、利用するクラスタのバージョンで現在の対応状況を必ず確認してください。コンテナのメモリ制御はsystemdのcgroupと密接に関わります。仕組みはsystemdとは何か？Linuxにおける役割と概要解説もあわせて参照すると理解しやすくなります。

データベースサーバーでのswappiness推奨値と設定理由

MySQLやOracleのようなDBは、自前でメモリ（バッファプール等）を管理するため、OSに勝手にスワップされると性能が大きく劣化します。これらのサーバーでは vm.swappiness=1 まで下げ、スワップをほぼ使わせない設定が推奨されます。0ではなく1にするのは、本当の枯渇時には最小限のスワップで延命させ、突然のOOM Killを避けるためです。インメモリ型データストアでも考え方は同じで、RAMに収める前提で設計します（参考：Valkeyとは何か？インメモリ型のオープンソース高性能キーバリューストアの概要と特徴）。

スワップ多発時の切り分け手順｜vmstatとsmemで原因を分類

スワップが多発したときの対処は、原因の切り分けから始めます。順番は固定です。まず本当に害が出ているか（vmstatのsi/soが継続的に非ゼロか）を確認し、出ているなら犯人プロセスをsmem／VmSwapで特定します。

次に原因を分類します。特定プロセスが時間とともにメモリを食い続けるならメモリリークの疑いがあり、valgrind などで該当プロセスを調査します。リークではなく単純な容量不足なら、RAM増設かインスタンスのスケールアップが根本対策です。空きRAMがあるのにスワップが進む場合だけ、vm.swappiness を下げて調整します。一時的にスワップを止めて切り分けたいときは sudo swapoff -a で全無効化、sudo swapon -a で再有効化できます。

避けるべきは、原因を見ずにいきなりswappinessを0にしたりスワップを全削除したりすることです。空きRAMが乏しい環境でこれをやると、安全弁を外した状態になり、軽い負荷増でOOM Killを招きます。スワップを減らす前に、必ずRAMの余裕を確認してください。切り分けの記録を残しておくと、再発時の初動が早くなります。

よくある質問

vm.swappinessの0と1は何が違いますか？

1はスワップを最小限に抑えつつ、枯渇時には少量だけ退避させます。一方カーネル5.8以降の0は「他に手段が無いときだけスワップする」挙動で、より強くスワップを避けます。空きRAMが少ない本番では、0より1のほうがOOM Killを避けやすく安全です。DBサーバーで1が推奨されるのはこのためです。

AWSのEC2にswapが無いのはなぜですか？

多くのEC2インスタンスは既定でスワップを持ちません。ストレージのEBSがサイズ課金で、スワップのI/Oがコストと性能に直結するためです。必要ならスワップファイルを追加できますが、本番で常用が必要になった時点で、インスタンスサイズの見直しを優先するのが定石です。

Linuxの推奨スワップサイズはどれくらいですか？

RHELのガイドラインでは、RAM 2GB以下はRAMの2倍、2GB超〜8GBはRAMと同量、8GB超〜64GBは最低4GB、64GB超も最低4GB（いずれもハイバネート未使用時）が目安です。RAMが多いほどスワップ比率は下げてよく、サイズはワークロードの瞬間的なメモリ超過量で判断します。

スワップは無効化してもいいですか？

RAMに十分な余裕があり、OOM時にプロセスが落ちても許容できる用途なら無効化は選択肢です。sudo swapoff -a で止められます。ただし安全弁を失うため、本番サーバーでは無効化よりswappinessを下げる方が安全です。Kubernetesノードのように、無効化が前提の環境もあります。

スワップ使用量を確認するコマンドは何ですか？

全体量は free -h、領域ごとの内訳は swapon --show または cat /proc/swaps、推移の監視は vmstat 1 のsi/so列、プロセス別は smem や /proc/[pid]/status のVmSwapで確認します。

関連記事

• systemdとは何か？Linuxにおける役割と概要解説
• Ubuntuのインストール手順と必要なシステム要件について
• Valkeyとは何か？インメモリ型のオープンソース高性能キーバリューストアの概要と特徴をわかりやすく解説