解決策 1:
これは完全に正常です。
システムの起動時に、多数のサービスが開始されます。これらのサービスは、自身の初期化、構成ファイルの読み込み、データ構造の作成などを行います。彼らはいくらかのメモリを使用します。これらのサービスの多くは、使用していないため、システムが稼働している間は再び実行されることはありません。それらのいくつかは、数時間、数日、または数週間で実行される場合があります。しかし、このデータはすべて物理メモリにあります。
もちろん、システムはこのデータを捨てることはできません。文字通り決してアクセスされないことを証明することはできません。たとえば、これらのサービスの 1 つは、ボックスへのリモート アクセスを提供するものである可能性があります。 1 週間使用していないかもしれませんが、使用した場合は、より効果的です。
しかし、システムは、その物理メモリをディスク キャッシュなどに使用したり、パフォーマンスを向上させる他の方法で使用したりする可能性があることを認識しています。したがって、日和見スワッピングを行います。他にやるべきことがない場合、スワップ領域を使用して、非常に長い間使用されていないデータをディスクに書き込みます。ただし、ページは引き続き物理メモリに保持されます。そのため、スワップインしなくてもアクセスできます。
これで、後でシステムが別の目的でその物理メモリを必要とする場合、それらのページはスワップするように既に書き込まれているため、単にそれらのページを破棄できます。これにより、システムは両方の利点を最大限に活用できます。データは引き続きメモリに保持されるため、ディスクから読み取ることなくアクセスできます。ただし、システムが別の目的でそのメモリを必要とする場合、最初に書き出す必要はありません。すべてにおいて大きな勝利。
解決策 2:
これは、過去のある時点で、マシンに搭載されている物理 RAM よりも多くのメモリが必要になった場合に発生する可能性があります。その時点で、いくつかのデータがスワップ領域に書き込まれます。
後でメモリが解放されると、スワップからのデータは自動的に RAM に読み込まれません。これは、スワップ内のデータが実際に何らかのプロセスで必要とされる場合にのみ発生します。これは完全に正常です。
mysql プロセスに関しては、これはすべて、実行するクエリのタイプによって異なります。理論的には、ユーザー数に関係なく、2 つの非常に複雑なクエリでこのような負荷を得ることができます。スロー クエリ ログを有効にして、どのクエリが負荷を集中的に使用しているかについてより多くの洞察を得ることができます。
解決策 3:
sysctl -w vm.swappiness=10 でこの動作を変更することもできます これにより、実際に必要になるまでスワップの使用を大幅に減らすことができます。
MySQL に関しては、少なくともtuning-primer.sh スクリプトを使用してベースライン構成テストを実行しましたか?