空きメモリーが多い永久スワップ

32G RAMがインストールされ、16Gスワップが設定されているDebian 4.0.5（カーネル4.0.0-2）を実行するLinuxサーバーがあります。システムはパーティショニングに lxc コンテナを使用しますが、ここでは重要ではありません。問題は、他のコンテナの内側と外側に存在します。

典型的なものは次のとおりですfree -h。

              total        used        free      shared  buff/cache   available
Mem:            28G        2.1G         25G         15M        936M         26G
Swap:           15G        1.4G         14G

/proc/meminfo持つ

Committed_AS:   12951172 kB

したがって、割り当てられたすべてを実際にすぐに使用しても、まだ空きメモリがたくさん残ります。ただし、システムは実行中のプロセスもすぐにページングします。

iotopこれは、Unicornを使用するRailsアプリケーションであるGitlabで最も顕著です。新しく分岐したUnicornワーカースレッドはすぐに交換され、要求が受信されるとディスクから約1400 kB / s（のデータ）で読み取られ、タイムアウト（現在30秒）を設定して、いつでも再起動できます。通常の要求はメモリに完全にロードされ、すぐに終了するまで5秒以上かかることはありません。これは単なる例であり、redis、amavis、postgres、mysql、java（openjdk）などでこれが起こるのを見ました。

それ以外の場合は、システムの負荷が低く、CPU使用率が約5％、負荷平均が約2（8コア）です。

私たちが試したこと（特定の順序なし）：

1. swapoff -a：800M程度交換失敗
2. 削減された交換性を使用します（段階別）sysctl vm.swappiness=NN。まったく効果がないようです。 0％に低下しましたが、まだ同じ動作をしています。
3. 必須ではないサービス（JettyベースのWebアプリケーション、Gitlab ...）を停止しておおよそのリリースします。 8GのコミットされたがマップされていないメモリとComfilled_ASを約5Gに減らします。まったく変わったことはありません。
4. 明確なシステムキャッシュを使用してくださいsync && echo 3 > /proc/sys/vm/drop_caches。これはメモリを解放しますが、スワップケースには何もしません。
5. 上記の組み合わせ

テストでfstabを介してスワップを完全に無効にするためにシステムを再起動することは、実際にはオプションではありません。一部のサービスには可用性の問題があり、「狩り」ではなく計画されたダウンタイムが必要なためです。そして、私たちは通常スワップを無効にしたくありません。 。

ここでなぜ交換が起こるのか理解できません。何が起こるのかというアイデアはありますか？

---

この問題はしばらく存在していましたが、高いIO負荷（長いバックグラウンドデータ処理操作）中に最初に現れたため、特定のイベントを正確に見つけることはできません。この作業が完了してから数日が経過しましたが、問題は引き続き解決され、この質問が発生します。