RAMに十分な空き容量があるのに、なぜスワップを使用するのですか？

RAMの代わりにスワップ領域を使用すると、PCの速度が大幅に低下する可能性があります。

なぜ、十分なRAMを使用できるのに、Linuxシステム（Arch）がスワップを使用するのですか？

以下のconky出力をチェックアウトします。

また、これは私が持っている速度とシステム応答性の問題の原因になる可能性がありますか？

出力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システムを使用することが通常であるいくつかの空きRAMがまだある場合でもスワップを。Linuxカーネルは、めったに使用されないスワップメモリ​​ページに移動しgettyます（たとえば、X11と他の非アクティブデーモンのみを使用するインスタンス）。

スワップスペースの使用は、十分なRAMが利用できない場合にのみ問題になり、カーネルは、アプリケーションを実行し続けるために、メモリページをスワップおよびRAMに連続的に移動することを強制されます。この場合、システムモニタアプリケーションは多くのディスクI / Oアクティビティを示します。

比較のために、GNOMEデスクトップを実行している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

ルート（例sudo nano /etc/sysctl.conf）として、行を変更または追加します（ない場合）。

vm.swappiness

目的の値に。このファイルが存在しない場合（Arch Linuxなど）、/etc/sysctl.d/99-sysctl.conf代わりに試してください。

利用可能な空きメモリを使用したスワップアウトが良いか悪いかについては議論がありましたが、Ubuntuのヘルプでは、デスクトップシステムの値として10を推奨しています。CentOSのDigital Oceanに関するこのチュートリアルも参照してください。

LinuxはRAMがいっぱいになる前にスワップを開始します。これは、パフォーマンスと応答性を改善するために行われます。

• プログラムメモリを保存するよりもRAMがディスクキャッシュに使用されることがあるため、パフォーマンスが向上します。そのため、しばらく非アクティブだったプログラムをスワップアウトし、代わりに頻繁に使用されるファイルをキャッシュに保存する方が適切です。

• メモリがいっぱいで一部のプログラムが実行されてタスクを完了するためにより多くのRAMを要求するときではなく、システムがアイドル状態のときにページをスワップアウトすることにより、応答性が向上します。

もちろん、スワッピングはシステムの速度を低下させますが、スワッピングの代替手段はスワッピングではなく、RAMを増やすか、使用するRAMを減らすことです。

これは古い記事ですが、私はここで自分の考えを述べる自由をまだとっています。

Linuxは最初からメモリをページに分割します（通常、x86_64システムではページごとに4K）。その後、仮想メモリが作成され、そのマッピングは、MMU（メモリ管理ユニット）を使用して物理メモリで行われます。

プロセスには仮想メモリ領域からメモリが割り当てられるため、/ proc / meminfoを表示すると、仮想メモリの詳細としてVMalloc *が表示されることに注意してください。

メモリを要求するプロセスがあるとしましょう（300MB-Webブラウザなど）。プロセスには、仮想メモリから300MBが割り当てられますが、メモリがマップされている（物理メモリにマップされている）必要はありません。メモリ管理には「コピーオンライト」の概念があります。これにより、プロセスが仮想メモリから割り当てられたメモリを実際に使用する場合（つまり、メモリに何らかの書き込みを行う場合）、物理メモリにマップされます。これにより、マルチプロセス環境でカーネルが効率的に正しく動作するようになります。

キャッシュとは何ですか？

プロセスで使用される多くのメモリが共有されます。glibcライブラリがほとんどすべてのプロセスで使用されているとしましょう。すべてのプロセスが同じメモリ位置にアクセスしてジョブを実行できるときに、glibcの複数のコピーをメモリに保持するポイントは何ですか。このような頻繁に使用されるリソースはキャッシュに保持されるため、プロセスが要求したときに同じメモリロケーションを参照できます。これは、ディスクからglibc（etc。）を何度も何度も読み込むのに時間がかかるため、プロセスの高速化に役立ちます。

上記は共有ライブラリについての例でしたが、ファイル読み取りについても同様です。大きなファイル（100〜200MBなど）を初めて読み込む場合は、時間がかかります。ただし、同じ読み取りを再度試行すると、高速になります。データはメモリにキャッシュされ、すべてのブロックで再読み取りは行われませんでした。

バッファーとは

バッファに関する限り、プロセスがファイルI / Oを実行する場合、カーネルのバッファに依存してデータをディスクに書き込みます。プロセスは、ジョブを実行するようカーネルに要求します。そのため、プロセスに代わって、カーネルはデータを「バッファー」に書き込み、書き込みが完了したことをプロセスに伝えます。非同期的に、カーネルはバッファー内のこのデータをディスクに同期し続けます。このように、プロセスはデータをディスクに同期するための正しい時間を選択するためにカーネルに依存しており、プロセスは先に進み続けることができます。これは、通常のプロセスが実行している一般的なI / Oであることに注意してください。ただし、I / Oが実際にディスク上で実行されることを確認する必要がある特殊なプロセスは、ディスク上でI / Oを実行するために他のメカニズムを使用できます。オープンソースユーティリティの一部はlibaioです。また、プロセスコンテキストで開かれたFDに対して明示的な同期を呼び出す方法があります。

ページ違反とは何ですか？

バイナリが約300MBのプロセス（Webブラウザーなど）を開始するときの例を考えてみましょう。ただし、完全な300MBのWebブラウザーバイナリはすぐには動作しません。プロセスは、コード内で関数から関数に移動し続けます。前述のように、仮想メモリは300MB消費されますが、すべてがメモリに物理メモリにマップされるわけではありません（RSS-常駐メモリは少なくなります、上の出力を参照）。コード実行が実際に物理的にマップされていないポイントに達すると、ページフォールトが問題になります。カーネルはこのメモリを物理にマップし、メモリページをプロセスに関連付けます。このようなページフォールトは「マイナーページフォールト」と呼ばれます。同様に、プロセスがファイルI / Oを実行すると、メジャーページフォールトが発生します。

スワップアウトが発生するタイミングと理由

状況1：

上記の詳細に沿って、適切な量のメモリがメモリマッピングされるシナリオを考えてみましょう。そして今、プロセスが起動しますが、これにはメモリが必要です。上記で説明したように、カーネルはメモリマッピングを行います。ただし、メモリをマップするのに十分な物理RAMがありません。これで、カーネルは最初にキャッシュを調べ、使用されていない古いメモリページをいくつか持つことになります。これらのページを別のパーティション（SWAPと呼ばれる）にフラッシュし、一部のページを解放し、解放されたページを新しい要求にマップします。ディスクへの書き込みはソリッドステートRAMよりもはるかに遅いため、このプロセスには多くの時間がかかり、そのためスローダウンが発生します。

状況2：

システムで使用可能な空きメモリがたくさんあるとしましょう。それでも、多くのスワップアウトが発生していることがわかります。メモリの断片化の問題が発生する可能性があります。カーネルに50MBの連続したメモリを必要とするプロセスを検討してください。（連続して心に留めてください）。明らかに、カーネルはページを異なるプロセスにランダムに割り当て、それらのいくつかを解放します。ただし、連続したメモリを要求する場合、プロセスの要求を満足させるチャンクを探す必要があります。そのようなメモリを取得できない場合は、いくつかの古いメモリページをスワップアウトしてから、連続したページを割り当てる必要があります。そのような場合でも、スワップアウトが発生します。Kernel ver 2.6以降では、このような断片化の問題は大幅に減少しています。ただし、システムが長時間実行されている場合は、このような問題が引き続き発生する可能性があります。

この例を参照（vmstat出力）

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-triggerを使用してこれらを確認し、出力はsyslogに記録されます）。

私たちの通常のシステムでは、ゾーン情報の比較はこれになります。また、cache / free / low memのグラフについても以下で説明します

情報を見ると、ノード0およびノー​​ド1の通常のメモリフラグメンテーションがあることが明らかです（ノードはNUMAベースのマシンであるため、複数のノードです（システムの情報を確認するにはnumactlを参照）。

メモリの断片化は、空きメモリがある場合でもスワップの使用量が増加する理由でもあります。

使用可能なメモリを増やす

誰もが言ったように、yesスワップは未使用のメモリを取り除くのに役立つので、利用可能なメモリを増やすのに役立ちます。

冬眠

ただし、スワップは冬眠にも使用できます。これは、ラップトップを持っている場合や、エネルギーを節約し、仕事を離れる前にコンピューターを休止状態にして作業したい場合に非常に役立ちます。そのため、翌朝早くスタートすることができます。

休止機能を持つことは、少なくともスワップ用のRAMのサイズを確保することを推奨する今日の主な理由の1つです。これにより、システムは使用済みのRAMをすべてスワップに入れ、休止状態に移行できます。

短所

スワップが暗号化されていない限り、一度スワップされたプロセスデータは、シャットダウン後でもスワップ内で読み取れることに注意してください（もちろん）。

休止状態で暗号化されたスワップを使用することは、すべてのディストリビューションですぐに動作するわけではありません。一定の暗号化キー（一部のセットアップはブートごとにランダムにスワップ空間暗号化キーを生成します）とinitrd / initramfsを使用して、再開する前に暗号化されたボリュームをアクティブにする必要があります。

多くの最新のプログラムは肥大化したフレームワーク上に構築されており、プログラムを実行するために実際には必要のない多くのジャンクをドラッグします。これらの未使用ページをスワップアウトすると、RAMがキャッシュと実際にRAMを使用できるプログラム用に解放されます。

私はここで苦しい個人的な経験から話しています。

昨年、私はWebサイトの1つをFirefoxの上に構築された有望な新しいWebサーバーフレームワークに切り替えました。Firefoxのようなクライアント中心のプログラムの上にサーバー側システムを構築するのは奇妙に聞こえるかもしれませんが、いくつかの大きな利点がありました。Firefoxは非常に強力で、いくつかの非常に印象的な内部サービスを提供し、サーバーとクライアント間のインピーダンスのミスマッチを減らして、両方が同様のプラットフォームを実行するようにします。

しかし、欠点があります：Firefoxは大きいです。本当に大きい。これはバージョン1.xの一種のプロジェクトだったので、GUIサポートを削除するようなことはしていませんでした。[*]私のサイトはそれを必要としませんでした。 tスワップスペース、そのGUIコード、Firefoxの他のすべての部分を許可しましたが、実際のRAMは使用しませんでした。サイトを実行するために、メモリが枯渇してクラッシュすることなく、最低 512 MBのRAMが必要になりました。私のVPSにいくらかのスワップスペースがあれば、おそらく256 MBのプランを手に入れることができたでしょう。

[*] このプラットフォームの利点の1つは高忠実度のWebスクレイピングだったため、フレームワークからGUIコードを削除することさえ望ましくない場合がありました。クライアント側と同じように。マッシュアップを考えてください。Webページを何らかのグラフィカルコンテキストに「レンダリング」できない場合、そのようなことの多くは壊れます。

ちなみに、このWebフレームワークは今や本質的に死んでいるので、名前を付けて見せかけの意味はありません。より広い教訓を心に留めておくことをお勧めします。はい、空きRAMを使用している場合でも、スワップは依然として有用です。

Ubuntuのスワップよくある質問マルセルはにリンクされています

基本的な最小値として、スワップ領域は物理メモリ（RAM）の量と等しくすることを強くお勧めします。また、スワップ領域は、ハードディスクの量に応じて物理メモリ（RAM）の2倍にすることをお勧めします

システムのスワップ領域を増やすべきだと思います。スワップは、すでにページングされたデータを破棄できるようにすることで、RAMメモリの割り当てを高速化します。

「Gilles」は既に十分なRAMを持っているかもしれないが、特定の「欠点」の間はスワップが有用であり、シャットダウン後も一部のデータを永続的に保存できるという事実をすでに述べていると思いますか？ RAMは再起動後にフラッシュされるため）システムで使用可能なRAMは12 GBであり、私も以前にこの質問について熟考しました。ある時点で、すべてのスワップを無効にし、RAMのみに依存していたとき、システムのシャットダウン後にシステムエラーやクラッシュなどをデバッグしようとするのは非常に困難な経験でした。それ以来、スワップパーティションを再度有効にしました。