以下に実稼働ホストがあります。

システムは1GBのスワップを使用し、40GB近くの空き未使用メモリスペースを維持しています。これについて心配する必要がありますか、それともほとんど正常ですか？

これは問題ではなく、おそらく正常です。多くのコード（および場合によってはデータ）が使用されることはほとんどないため、システムはそれをスワップアウトしてメモリを解放します。

スワップは、メモリが継続的にスワップインおよびスワップアウトされている場合にのみ問題になります。パフォーマンスを低下させ、システム上の他の場所に問題を示唆するのは、そのようなアクティビティです。

スワップアクティビティを監視する場合は、いくつかのユーティリティを使用できますがvmstat、通常は非常に便利です。

$ 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 348256  73540 274600    0    0     1     9    9    6  2  0 98  0  0
 0  0      0 348240  73544 274620    0    0     0    16   28   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   29   33  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   21   23  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   24   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   23   23  0  0 100  0  0

最初の行はシステムが起動してからのアクティビティであるため、無視してください。siとのso下の列に注意してください---swap--。ほとんどの場合、それらは0でない場合、通常はかなり小さい数字である必要があります。

また、言及する価値があるのは、このプリエンプティブスワッピングはカーネル設定で制御できることです。ファイルが/proc/sys/vm/swappinessメモリをスワップアウトする方法積極的にカーネルに指示します0〜100の数値が含まれています。ファイルをcatして、これが何に設定されているかを確認します。デフォルトでは、ほとんどのLinuxディストリビューションのデフォルトは60ですが、メモリが枯渇する前にスワッピングを表示したくない場合は、次のようにファイルに0をエコーし​​ます。

echo 0 >/proc/sys/vm/swappiness

これを追加することにより永続的にすることができます

vm.swappiness = 0

へ/etc/sysctl.conf。

Linuxは、それ以上実行する必要がない場合、ページをディスクに先取りして書き込みます。ただし、これらのページがメモリから削除されるわけではありません。それは場合にはそれだけであることですしなければならない、彼らはすでに存在しているので、将来的にそれらのページを追い出し、それは、彼らがディスクに書き込まれるのを待つ必要はありません。

結局のところ、メモリが不足している理由は、おそらくマシンがすでに一生懸命に動作しているためであり、スワップに追加の負荷をかけたくないためです。マシンが何もしていないときにスワッピングを行う方が良い。

同様の理由で、あなたの記憶は常に一杯でなければなりません。メモリページ、ファイルシステムキャッシュ、tmpfsなど、メモリに保持できるものはたくさんあります。本当に、あなたの記憶が空かどうか心配する必要があります。結局、（少なくとも同じディスク容量と比較して）それに多額のお金を払ったので、それはより良く使われます！

使用されるスワップは悪くありませんが、多くのスワップアクティビティは

  vmstat 1
  procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
  6  0 521040 114564   6688 377308    8   13   639   173    0 1100  5  4 90  0
  1  0 521040 114964   6688 377448    0    0   256     0    0 1826  3  4 94  0
  0  0 521040 115956   6688 377448    0    0     0     0    0 1182  7  3 90  0
  0  0 521036 115992   6688 377448    4    0    16     0    0 1154 10  2 88  0
  3  0 521036 114628   6696 377640    0    0   928   224    0 1503 15 17 67  1

列のスワップはまったく問題ありません。列の非ゼロ値は、SIとそのサーバーのパフォーマンスに致命的です。特に、RAMが大量にあるもの。

数GBのRAMを搭載したマシンでスワップインを無効にするのが最適です。

sysctl -w vm.swappiness=0

これはスワップを無効にしません。Linuxに最後の手段としてスワップを使用するよう指示するだけです。これにより、RAMに格納する必要のないプログラムが数MB無駄になります...しかし、ディスクアクセスキューの肥大化をスワップすることをお勧めします。

編集1：swappinessのデフォルト値が最適ではない理由

20年前、大きな486には32MbのRAMしかなかったことを思い出しました。スワップアルゴリズムは、RAM全体をほんの数秒でディスクに移動できるときに開発されました。その当時の遅いディスクでも。そのため、デフォルトのスワップポリシーは非常に積極的です。RAMは当時のボトルネックでした。それ以降、RAMサイズは10,000倍以上に増加し、ディスク速度は10倍未満になりました。これにより、ボトルネックがディスク帯域幅にシフトしました。

編集2：なぜこれほど活動がサーバーにとって致命的であるのか？

シリコンとなるよう RAMのトンとマシン上の活動が致命的であることを意味するため、システムはRAMのために自分自身と戦っています。起こることは、RAMと比較した場合、ディスク、さらには大きなストレージであっても遅すぎるということです。アグレッシブスワップは、アプリケーションデータよりもカーネルディスクキャッシュを優先し、RAMを奪う最も一般的なソースです。OSはsiごとにディスクキャッシュを解放する必要があるため、swapが提供する余分なキャッシュの有効期間は非常に短いため、とにかく有用ではありません。その結果、おそらく使用されないキャッシュを保存するためにディスク帯域幅を使用し、siページを待機しているプログラムを一時停止します。多くの重要なリソースを消費し、アプリケーションにほとんどまたはまったく利益をもたらさないという意味。

応答のタイトル「大量のRAMを備えたサーバーでの大量のスワップアクティビティ」に注意してください。これは、時折siなどのアクティビティがあるマシンには適用されません。OSでよりスマートなスワップアルゴリズムが開発されている場合、これは将来適用されない可能性があります。

編集3：「コールド」ページ

スワッピングアルゴリズムはロマンチックです。「RAMの使用ページが少なくて済む」という人もいますが、これはカーネルが行うことではありません。スワップについて理解するのが難しいのは、カーネルが「コールドページ」が何であるかを知らないことです。カーネルには、ページが使用されているか、近い将来使用される可能性があるかを判断するための適切なメトリックがありません。カーネルがページを多少ランダムにスワップに入れ、不要なページがそこに残ることを回避するため。このアルゴリズムの問​​題は、ページがアプリケーションに必要かどうかを知るためにページをスワップする必要があることです。これは、多くの「ホット」ページがスワップに移動することを意味します。それに伴う問題は、ディスクがRAMと比較して非常に遅いことです。

適切な量​​の多くのアプリケーションに非常によくある現実的なシナリオである独自のベンチマークを作成しました。私のテストから、スワップを使用しているときのスループットまたはレイテンシーにメリットはありませんでした。それからはほど遠い。スワップが開始されると、スループットとレイテンシの両方が少なくとも1桁遅くなります。

これについてもう少し詳しく説明します。スワップは処理用ではないことを理解しています。スワップは緊急時のみです。同時に多くのアプリケーションが実行されており、メモリスパイクが発生する瞬間。スワップがないと、メモリ不足エラーが発生します。スワップの使用は、開発チームと運用チームの失敗だと考えています。これは、ここで説明したことをはるかに超える意見ですが、私はそう思っています。もちろん、私のアプリケーションはそれ自体で優れたメモリ管理を備えています。

これはあなたの質問に対する答えではありません。むしろ、情報に基づいた決定を下すのに役立つ追加情報のみです。

具体的にどのプロセスがどのくらいのスワップを使用しているかを知りたい場合は、ここに小さなシェルスクリプトがあります：

#!/bin/bash

set -o posix
set -u

OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"` ; do
  PID=`echo $DIR | cut -d / -f 3`
  PROGNAME=`ps -p $PID -o comm --no-headers`

  SUM=0
  for SWAP in `grep Swap $DIR/smaps 2>/dev/null| awk '{ print $2 }'` ; do
    let SUM=$SUM+$SWAP
  done
  echo "PID=$PID - Swap used: $SUM - ($PROGNAME )"

  let OVERALL=$OVERALL+$SUM
done
echo "Overall swap used: $OVERALL"

また、tmpfsもスワップアウトすることを追加する必要があります。これは、tmpfsを使用してユーザー空間/ tmpオーバーレイを作成するsystemdを使用する最新のLinuxシステムでより一般的です。

エージェントが頻繁にスワップしていると、MySQL Clusterのレプリケーションが遅くなるか失敗することに気付きました。いくつかのアプリケーションは気にしないかもしれませんし、スワッピングの恩恵を受けるかもしれませんが、データベースは実際にそれで苦しむようです。しかし、私がフォーラムで見た多くの議論は、特定のワークロードの議論から非文脈化されたスワップについて議論しています。

DBAの世界では、コンセンサスは「MySQL（または実際に他のDBMS）を実行しているときは、スワップ空間にI / Oを見たくないという常識です。キャッシュサイズのスケーリング（使用innodb_buffer_pool_size（MySQLの場合）は、スワップが必要ないように十分な空きメモリがあることを確認する標準的な方法です。

しかし、何らかの間違いや計算ミスをして、スワッピングが発生したらどうなるでしょうか？パフォーマンスに実際にどの程度影響しますか？これはまさに私が調査しようとしたものです。」

読者の皆様が次のリンクが適切に見つかることを願っています。

https://www.percona.com/blog/2017/01/13/impact-of-swapping-on-mysql-performance/

https://www.percona.com/blog/2010/01/18/why-swapping-is-bad-for-mysql-performance/