RAMに十分な空き領域がある場合に、なぜswapを使用するのですか？
RAMの代わりにswapスペースを使用できます劇的に遅くなる PC。
では、なぜ十分な数以上のRAM=利用可能な場合、私のLinuxシステム（Arch）はスワップを使用するのですか？
以下の私の厄介な出力をチェックしてください：
また、これが速度とシステムの応答性の問題の原因になる可能性がありますか？
free -mの出力：
$ free -m
total used free shared buffers cached
Mem: 1257 1004 252 0 51 778
-/+ buffers/cache: 174 1082
Swap: 502 144 357
Linuxシステムがsome swapを使用するのは正常ですRAM freeがまだある場合でも。Linuxカーネルは、めったに使用されないスワップメモリページに移動します（例： 、X11のみを使用する場合のgettyインスタンス、およびその他の非アクティブなデーモン）。
スワップ領域の使用が問題になります十分なRAMが利用できない場合であり、カーネルはメモリページをスワップに継続的に移動し、RAMに戻します。この場合、システムモニターアプリケーションは多くのディスクI/Oアクティビティを示します。
比較のために、GNUデスクトップを実行しているX11セッションで2人のユーザーがログインしている私のUbuntu 10.04システムでは、〜600MBのスワップと〜1GBのRAM（バッファーとfsキャッシュはカウントしない））を使用しているため、スワップ使用量の数値は正常に見えると思います。
この動作は、次の値を設定することで構成できます。
/proc/sys/vm/swappiness
デフォルト値は60です。これを0に設定すると、RAMが残っており、100ができるだけ早くメモリをスワップアウトしている場合は、スワップを使用しません。
値を一時的に変更するには（再起動時に失われます）：
Sudo sysctl vm.swappiness=10
値を永続的に変更するには、ファイルを編集します。
/etc/sysctl.conf
root（例：Sudo nano /etc/sysctl.conf）として、行を変更または追加します（存在しない場合）。
vm.swappiness
希望の値に。このファイルが存在しない場合（Arch Linuxなど）、代わりに/etc/sysctl.d/99-sysctl.confを試してください。
利用可能な空きメモリとのスワップアウトが良いか悪いかについては議論が交わされていますが、 buntuヘルプでは、デスクトップシステムの値として10を推奨しています 。 CentOS用のDigital Oceanに関するこのチュートリアル も参照してください。
Linuxは、RAMがいっぱいになる前にスワップを開始します。これは、パフォーマンスと応答性を向上させるために行われます。
RAMは、プログラムメモリを格納するよりもディスクキャッシュに使用する方がよいため、パフォーマンスが向上します。そのため、しばらく使用されていないプログラムをスワップアウトし、代わりに頻繁に使用するファイルを保持することをお勧めします。キャッシュ。
メモリがいっぱいで、一部のプログラムが実行中であり、タスクを完了するためにさらにRAM=）を要求するときではなく、システムがアイドル状態のときにページをスワップアウトすることにより、応答性が向上します。
もちろんスワッピングはシステムの速度を低下させます—しかし、スワッピングの代替手段はスワッピングではなく、より多くのRAMまたはより少ないRAMを使用しています。
これは古い記事ですが、私はここに自分の考えを置く自由があります。
Linuxは、最初からメモリをページに分割します（通常、x86_64システムではページあたり4K）。その後、仮想メモリが作成され、そのマッピングはMMU（メモリ管理ユニット）を使用して物理メモリで行われます。
プロセスには仮想メモリ領域からメモリが割り当てられるため、/ proc/meminfoを表示すると、仮想メモリの詳細としてVMalloc *が表示されることに注意してください。
あなたがメモリを要求するプロセスを持っているとしましょう（例えば300MB-Webブラウザ）。プロセスには仮想メモリから300MBが割り当てられますが、メモリにマップされている（物理メモリにマップされている）必要はありません。メモリ管理には「コピーオンライト」の概念があります。これにより、プロセスが仮想メモリから割り当てられたメモリを実際に使用する場合（つまり、メモリ上に何らかの書き込みを行う場合）は、物理メモリにのみマップされます。これは、マルチプロセス環境でカーネルが効率的に適切に動作するのに役立ちます。
キャッシュとは何ですか？
プロセスが使用する多くのメモリが共有されます。 glibcライブラリがほとんどすべてのプロセスで使用されているとしましょう。すべてのプロセスが同じメモリ位置にアクセスしてジョブを実行できるときに、メモリにglibcの複数のコピーを保持することの意味は何ですか。このような頻繁に使用されるリソースはキャッシュに保持されるため、プロセスが要求した場合、それらは同じメモリロケーションを参照できます。これは、glibcなどをディスクから再度読み取るのに時間がかかるため、プロセスの高速化に役立ちます。
上記は言うまでもなく共有ライブラリの場合でしたが、ファイルの読み取りについても同様です。大きなファイル（たとえば100〜200 MB）を初めて読み取る場合は、かなりの時間がかかります。ただし、同じ読み取りをもう一度実行すると、処理が速くなります。データはメモリにキャッシュされ、すべてのブロックで再読み取りが行われませんでした。
バッファとは？
バッファに関する限り、プロセスがファイルI/Oを行う場合、カーネルのバッファを使用してデータをディスクに書き込みます。プロセスは、カーネルにジョブを実行するように要求します。したがって、プロセスに代わって、カーネルは「バッファ」にデータを書き込み、プロセスに書き込みが完了したことを通知します。非同期で、カーネルはこのデータをバッファ内のディスクに同期し続けます。このように、プロセスはカーネルがデータをディスクに同期する正しい時間を選択することに依存しており、プロセスは先に進み続けることができます。これは、通常のプロセスが実行している一般的なI/Oであることに注意してください。ただし、I/Oが実際にディスク上で実行されていることを確認する必要がある特殊なプロセスは、他のメカニズムを使用してディスク上でI/Oを実行できます。一部のオープンソースユーティリティはlibaioです。また、プロセスコンテキストで開かれたFDへの明示的な同期を呼び出す方法があります。これにより、カーネルが強制的にデータをディスクに同期して、書き込みを行うことができます。
ページフォルトとは何ですか？
例として、バイナリが約300MBのプロセス（Webブラウザなど）を開始するとします。ただし、Webブラウザーバイナリの完全な300MBはすぐには機能しません。プロセスは、コード内で関数間を移動し続けます。前述のように、仮想メモリは300MB消費されますが、すべてがメモリが物理メモリにマップされるわけではありません（RSS-常駐メモリは少なくなります。上の出力を参照してください）。コードの実行がメモリが実際に物理的にマップされていないポイントに到達すると、ページフォールトが問題になります。カーネルはこのメモリを物理にマップし、メモリページをプロセスに関連付けます。このようなページフォールトは、「マイナーページフォールト」と呼ばれます。同様に、プロセスがファイルI/Oを実行すると、メジャーページフォールトが発生します。
スワップアウトが発生する時期と理由
状況1：
上記の詳細に沿って、適切な量のメモリがメモリマップされるシナリオを考えてみましょう。そして今、メモリを必要とするプロセスが起動します。上で議論したように、カーネルはいくつかのメモリマッピングを行うでしょう。ただし、メモリをマップするのに十分な物理的なRAMが利用できません。カーネルは最初にキャッシュを調べ、使用されていない古いメモリページがいくつかあります。これらをフラッシュしますページを別のパーティション（SWAPと呼ばれます）に解放し、一部のページを解放し、解放されたページを新しい要求にマップします。ディスクの書き込みはソリッドステートRAMよりもはるかに遅いため、このプロセスには多くの時間がかかり、したがって速度が低下します見られます。
状況2：
システムで利用可能な空きメモリがたくさんあるとしましょう。それでも、多くのスワップアウトが発生していることがわかります。メモリの断片化の問題が発生している可能性があります。カーネルから50MBの連続したメモリを必要とするプロセスを考えます。 （連続することを覚えておいてください）。明らかに、カーネルはページをランダムに異なるプロセスに割り当て、それらのいくつかを解放します。ただし、連続したメモリを要求する場合は、プロセスの要求を満足させるチャンクを探す必要があります。そのようなメモリを取得できない場合は、古いメモリページの一部をスワップアウトしてから、連続するメモリページを割り当てる必要があります。このような場合でも、スワップアウトが発生します。カーネルバージョン2.6以降では、このような断片化の問題が大幅に軽減されました。ただし、システムが長時間稼働している場合でも、このような問題が発生する可能性があります。
この例を参照してください（vmstat output）
2016-10-29 03:55:32 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
2016-10-29 03:55:32 r b swpd free buff cache si so bi bo in cs us sy id wa st
2016-10-30 03:56:04 19 23 2914752 4692144 3344908 12162628 1660 1 8803 12701 4336 37487 14 7 40 38 0
2016-10-30 03:56:34 3 20 2889296 4977580 3345316 12026752 2109 2 8445 14665 4656 36294 12 7 46 34 0
2016-10-30 03:57:04 1 11 3418868 4939716 3347804 11536356 586 4744 2547 9535 3086 24450 6 3 59 33 0 <<<-----
2016-10-30 03:57:34 3 19 3456252 5449884 3348400 11489728 3291 13371 6407 17957 2997 22556 6 4 66 24 0
2016-10-30 03:58:04 7 6 4194500 5663580 3349552 10857424 2407 12240 3824 14560 2295 18237 4 2 65 29 0
2016-10-30 03:58:34 2 16 4203036 5986864 3348908 10838492 4601 16639 7219 18808 2575 21563 6 4 60 31 0
2016-10-30 03:59:04 3 14 4205652 6059196 3348760 10821448 6624 1597 9431 4357 1750 20471 6 2 60 31 0
2016-10-30 03:59:34 2 24 4206968 6053160 3348876 10777216 5221 2067 10106 7377 1731 19161 3 3 62 32 0
2016-10-30 04:00:04 0 13 4205172 6005084 3348932 10785896 6236 1609 10330 6264 1739 20348 4 2 67 26 0
2016-10-30 04:00:34 4 11 4206420 5996396 3348976 10770220 6554 1253 10382 4896 1964 42981 10 5 58 27 0
2016-10-30 04:01:04 6 4 4177176 5878852 3348988 10825840 8682 765 10126 2716 1731 32949 8 4 69 19 0
@ 2016-10-30 03:57:04、まだ十分な空き容量があることがわかりますRAM=使用可能です。ただし、それでもスワップアウトが発生しました。この時点でプロセスツリーを確認しました、そのような大量のメモリ（空きメモリ以上）を要求するプロセスが発生することはありませんでした。明らかな疑いは、上記の状況2です。上記のbuddyinfoおよびzoneinfoログを確認しました（echo m>/proc/sysrqを使用します-トリガーしてこれらをチェックすると、出力はsyslogに送られます）。
私たちの通常のシステムでは、ゾーン情報の比較はこれになります。また、キャッシュ/空き/低メモリのグラフも以下に記載されています
情報を見ると、通常のノード0とノード1にメモリの断片化があることがわかります（ノードはNUMAベースのマシンなので、複数のノードです（システムの情報を確認するにはnumactlを参照））。
メモリの断片化も、空きメモリがある場合でもスワップの使用量が増える可能性がある理由です。
より多くの利用可能なメモリを持っています
みんなが言ったように、はいスワップは未使用のメモリを取り除くのに役立つので、より多くのメモリを利用できるようにするのに役立ちます。
休止状態
しかし、スワップはhibernatingにも使用できます。これは、ラップトップを持っている場合や、仕事を辞める前にエネルギーを節約してコンピューターを休止状態にしたい場合に非常に役立ちます。そのため、翌朝の開始時間を短縮できます。
休止機能があることは、現在でも少なくともRAMのサイズのスワップが必要です）とアドバイスされている主な理由の1つです。これにより、システムはすべての使用済みRAMをスワップに入れて休止状態に入ります。
ショートカミング
（もちろん）スワップが暗号化されていなければ、一度スワップされたプロセスデータはシャットダウン後でもスワップ内で読み込まれる可能性があることに注意してください。
休止状態で暗号化されたスワップを使用しても、すべてのディストリビューションですぐに動作するわけではありません。再開する前に、一定の暗号化キー（一部のセットアップでは、起動ごとにランダムにスワップ領域の暗号化キーを生成します）とinitrd/initramfsを使用して暗号化されたボリュームをアクティブにする必要があります。
マルセルがリンクした buntu Swap F.A.Q。 から
基本的な最小値として、スワップスペースは物理メモリ（RAM）の容量と同じにすることを強くお勧めします。また、ハードディスクの容量に応じて、スワップスペースを物理メモリ（RAM）の2倍にすることをお勧めします。
システムのスワップ領域を増やす必要があると思います。スワップは、すでにページングされたデータを破棄できるようにすることで、RAMメモリ割り当てを高速化します。
最新のプログラムの多くは、プログラムを実行するために実際には必要ではない多くのジャンクを引き込む肥大化したフレームワークに基づいて構築されています。これらの未使用のページをスワップアウトすると、RAM=実際にRAMを使用できるキャッシュおよびプログラム用に解放されます。
ここで私は辛い個人的な経験から話します。
昨年、私は自分のWebサイトの1つを、Firefoxの上に構築された有望な新しいWebサーバーフレームワークに切り替えました。 Firefoxのようなクライアント重視のプログラムの上にサーバー側システムを構築するのは奇妙に聞こえるかもしれませんが、いくつかの大きな利点がありました。 Firefoxは非常に強力で、いくつかの非常に印象的な内部サービスを提供します。また、サーバーとクライアント間のインピーダンスの不一致を減らし、両方で同様のプラットフォームを実行します。
しかし、欠点もあります。Firefoxが大きいことです。本当に大きい。これはバージョン1.xの一種のプロジェクトだったので、GUIサポートの削除などに慣れていませんでした。[*]私のサイトにはそれは必要ありませんでしたが、私のホスティングプロバイダーが使用していたVPSテクノロジーはスワップスペース、そのGUIコード、および私が使用しなかったFirefoxの他のすべての部分は、実際のRAMを使用しませんでした。最終的に512 MBが必要になりましたRAM minimumメモリ不足のためにクラッシュせずにサイトを実行するためだけです。私のVPSにスワップスペースがある場合、おそらく256 MBプランで。
[*] このプラットフォームの利点の1つは、サーバー側のフレームワークが別のサイトからWebページをダウンロードでき、ユーザーが操作するのと同じように操作できるため、フレームワークからGUIコードを削除することは望ましくなかったかもしれません。クライアント側になります。マッシュアップを考えてください。 Webページをグラフィックコンテキストに「レンダリング」できない場合、そのようなことの多くはうまく機能しません。
ちなみに、このWebフレームワークは今や本質的に死んでいるので、名前を付けたり、それを構成したりする意味はありません。幅広い教訓を心に留めておくのが最善です。はい、空きRAMがギグしても、スワップは役立ちます。
「ギルズ」は、RAMが十分にある場合でも、特定の「欠点」や、シャットダウン後も永続的に一部のデータを保存するときにスワップが役立つという事実をすでに言及していると思います-またはそれを仮定するのは間違っていますか？ RAMがフラッシュされるため）私は12GBのRAMがシステムで利用可能であり、私もこの質問について以前に考えました。ポイント、すべてのスワップを無効にし、RAMのみに依存していた場合、システムのシャットダウン後にシステムエラーやクラッシュなどをデバッグしようとすると、非常に困難な経験がありました。それ以来、スワップパーティションを再度有効にしました。