Linux centOSシステムがアイドル状態ですが、kswapdは100%cpuを使用しています。
私が実行しているのは、トップランニングの単一のbashセッションだけです... 32G RAMを使用していますが、kswapdは常に100%cpuを4時間以上使用しています。
AFAICSこれは無料とは関係ありませんRAMまたはSWAP。ここで同じ問題が発生することがあり、本番マシンにヒットすることもあり、RAM無料、かなり頻繁に700 MB以上、同期するダーティバッファーがなく、0バイトのSWAPが使用されていることいくつかの不明な競合状態が原因で、カーネルBUGのように見えます。
現在、CentOSカーネル2.6.18-194.el5を実行しており、新しいカーネルに置き換えようとしています。
更新:
RedHatは、それが2.6.18-194.el5のカーネルの問題であることを確認していました
ソリューション:
Minimum: kernel-2.6.18-194.32.1.el5 contains the immediate bugfix Better: kernel-2.6.18-238.el5 contains additional kswapd-related bugfixes Best: kernel-2.6.18-348.4.1.el5 latest kernel which runs with RHEL 5.5 without change
その間、 スクリプトがあります 、これは100%CPUの状況を非常によく検出できます。毎分監視によって呼び出され、状況を知らせます。状況が長すぎる場合、影響を受けるマシンは、マシンが完全に管理不能になるまで、100%のCPUを使用するますます不可能なプロセスのために完全にロックアップします。
現在問題を解決するために知られている唯一の方法は、影響を受けるマシンを手動でハードリブートすることです。 /sbin/reboot
は失敗します。シャットダウン時にマシンが非常に頻繁にハングするためです。
コンソールに直接アクセスせずにルートシェルのコマンドラインからマシンをハードリブートするには、次のようにします。
echo 10 > /proc/sys/kernel/panic
echo 1 > /proc/sys/kernel/sysrq
echo s > /proc/sysrq-trigger
sleep 5
echo s > /proc/sysrq-trigger
sleep 1
echo b > /proc/sysrq-trigger
マシンの休止後にこれを行うことを覚えておいてください。ディスクに書き込むプロセスがなくなるためです。これにより、再起動後にfsck
が深刻な問題で実行されるのを防ぐことができます。
申し訳ありませんが、実際の解決策はありませんが、HTHです。また、kswapdでCPUの状態が100%になる原因は、ここで説明したもの以外にもある可能性があることに注意してください。したがって、この場合の再起動の自動化はおそらく悪い考えです。