解決策 1:
kswapd は、すべての物理的に利用可能なメモリを超えるメモリ要求に対応して、スワップ領域を管理しています
これはプロセスに依存せず、どのページがいつアクセスされたかのみに関心があります (もちろん、これよりも複雑ですが、物事をシンプルに保つために、このように表示することもできます)。
だから本物 問題は、「kswapd が常にページングする必要がある原因となっている、メモリに最大の負担をかけているプロセスはどれか」です。
これは、'top' を使用し、メモリ使用量の並べ替えモードに切り替えることで最も簡単に解決できます。
解決策 2:
あなたはそれをスクリプト化することができます..しかし、トップ経由でそれを行うこともできます
トップを実行して O を押します 続いて p 次に入る
すべてのプロセスがスワップの使用状況でソートされ、どのプロセスがそれを使用しているかを確認できます
解決策 3:
Ubuntu 15.10 以降を使用している場合、特にシステムがスワップ パーティションのない仮想マシン (AWS EC2 など) の場合、これは実際にはバグの結果である可能性があります。この問題は他のディストリビューションにも存在しますが、執筆時点では、同じ修正が普遍的に機能するかどうかは不明です.
一時的な回避策:
sudo ln -s /dev/null /etc/udev/rules.d/40-vm-hotadd.rules
sudo reboot
これにより、Xen および Hyper-V 仮想マシンの RAM/CPU のホットアドが無効になることに注意してください。
解決策 4:
kswapd にもバグがあるようです どこかで、できれば古いカーネルでのみ。
ほぼ毎日、大規模なクラスター内の一部のマシンで kswapd がランダムに暴走します (ただし、最新のカーネルではありません)。両方の kswapd プロセスで 100% の CPU。他の実行中のプロセス (ssh シェルを除く) はなく、十分な空き RAM (700 MB 以上) があり、SWAP はまったく使用されていません。スワップインもスワップアウトもありません。
特定のマシンがヒットし、別のマシンがヒットしない理由はまだ説明されていません。通常、短時間に複数のマシンにヒットするため、完全にランダムではないようです。アイドル状態のマシンや高圧下のマシンは、影響を受けにくい (!) ようです。そのため、作業負荷を処理する必要があり、マシンがアイドル状態でもビジー状態でもない場合にのみヒットします。
問題が発生した場合、何も役に立ちません。すべてのプロセスを強制終了し（強制終了できなくなりませんでした）、すべてのファイルシステムをアンマウントしますが、何もしません。 kswapd CPU 使用率は 100% のままです。 SMP カーネルでスピンロックの競合が発生していると思われますが、間違っている可能性もあります。
おそらく私の回答をご覧ください serverfault.com/questions/316995/#493257
注:
- 影響を受けたマシンの再起動は、シャットダウン プロセスがどこかで停止し始めるため、しばしば失敗します。
- インターネットへの直接接続はありません。外部の原因はありそうにありません。
- 負荷の観点からは、マシンが処理するワークロードのタイプに依存しているようです。これは、(まだ) 影響を受けていないマシンがあるためです。
- 申し訳ありませんが、私たちの活動とその理由について、これ以上具体的にお伝えすることはできません.
- はい、憶測です。というのも、今日は非常に不可解な効果です。