web-dev-qa-db-ja.com

大量の空きメモリを使用した永続的なスワッピング

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

したがって、割り当てられたすべてが実際に一度に使用された場合でも、十分な空きメモリがあります。ただし、システムは実行中のプロセスでも即座にページングします。

これはGitlabで最も顕著であり、Rails Unicornを使用するアプリケーション：新しくフォークされたUnicornワーカーは即座に交換され、リクエストが発生すると、ディスクから最大1400kB/sで読み取る必要があります（からのデータiotop）そしてタイムアウト（今のところ30秒、時間内に再起動するため。通常のリクエストは5秒以上かかることはありません）に達してから完全にメモリにロードされるため、即座に強制終了されます。これはただのことです。例として、これがredis、amavis、postgres、mysql、Java（openjdk）などで発生するのを見てきました。

それ以外の場合、システムは低負荷の状況にあり、CPU使用率は約5％、負荷は約2（8コア）です。

私たちが試したこと（順不同）：

  1. swapoff -a：約800Mで失敗しますがまだスワップされています
  2. sysctl vm.swappiness=NNを使用してswappinessを（段階的に）削減します。これはまったく影響がないようです。0％まで下げましたが、それでもまったく同じ動作が存在します。
  3. 必須ではないサービス（Gitlab、JettyベースのWebアプリ...）を停止し、約8Gのコミットされているがマップされていないメモリで、Committed_ASを約5Gに下げます。まったく変化はありません。
  4. sync && echo 3 > /proc/sys/vm/drop_cachesを使用してシステムキャッシュをクリアします。これによりメモリが解放されますが、スワップの状況には何の影響もありません。
  5. 上記の組み合わせ

一部のサービスには可用性の問題があり、「突っつい」ではなく計画的なダウンタイムが必要なため、テストとしてfstabを介してスワップを完全に無効にするためにマシンを再起動することは実際にはオプションではありません...また、スワップを無効にしたくない場合もあります。後退する。

ここでスワッピングが発生している理由がわかりません。何が起こっているのか考えはありますか？

この問題はしばらく前から存在していましたが、IO負荷（長いバックグラウンドデータ処理タスク）の高い期間に最初に発生したため、特定のイベントを特定できません。このタスク数日間行われ、問題が解決しないため、この質問があります。

linuxdebianswaplxccgroups
6
Martok

私が言ったことを覚えておいてください：

システムは区画化にlxcコンテナーを使用しますが、ここでは問題になりません。

さて、それはdidの問題であることがわかりました。むしろ、lxcの中心にあるcgroupが重要です。

ホストマシンは、カーネルアップグレードの再起動のみを認識します。では、最後に使用されたカーネルは何でしたか？ 3.19、2か月前は4.0.5に、昨日は4.1.3に置き換えられました。そして、昨日何が起こったのですか？左、右、中央を巧みに操るプロセス。 /var/log/kern.logを確認すると、影響を受けたプロセスは512Mのメモリを持つcgroupにありました。待って、512M？それは正しくありません（予想される要件が約4Gの場合！）。結局のところ、これは、数か月前にこれをすべて設定したときにlxcconfigsで構成したものとまったく同じです。

つまり、3.19はcgroupのメモリ制限を完全に無視したということです。 4.0.5は、cgroupが許可されている以上のものを必要とし（これがこの質問の中心的な問題です）、4.1.3のみが完全なmemkiller-sweepを実行する場合に常にページングされます。

ホストシステムのswappinessは、物理メモリが不足することはほとんどなかったため、これには影響しませんでした。

ソリューション：

一時的な変更の場合、cgroupを直接変更できます。たとえば、box1という名前のlxcコンテナーの場合cgroupはlxc/box1と呼ばれ、（ホストマシンのrootとして）実行できます。

$ echo 8G > /sys/fs/cgroup/memory/lxc/box1/memory.limit_in_bytes

永続的な解決策は、/var/lb/lxc/...でコンテナーを正しく構成することです。

lxc.cgroup.memory.limit_in_bytes = 8G

ストーリーのモラル：常に構成を確認してください。それが問題になる可能性はないと思っていても（そして実際に失敗するには、カーネル内の別のバグ/不整合が必要です）。

8
Martok