У меня простаивающая система CentOS Linux, но kswapd использует 100% процессор.
Все, что у меня есть, - это один сеанс bash с запуском сверху .... У меня 32 ГБ ОЗУ, но kswapd постоянно использует 100% процессор более 4 часов.
AFAICS это не связано ни со свободной оперативной памятью, ни с SWAP. У нас здесь та же проблема, которая иногда поражает производственные машины, и там много свободной оперативной памяти, довольно часто более 700 МБ без грязных буферов для синхронизации и использования 0 байтов SWAP. Это определенно выглядит как серьезная ОШИБКА ядра из-за неизвестного состояния гонки.
В настоящее время мы запускаем ядро 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% -ную ситуацию с процессором. Наш мониторинг каждую минуту вызывает его, чтобы проинформировать нас о ситуации. Если ситуация продлится слишком долго, затронутые машины будут полностью заблокированы из-за того, что все больше и больше неуклонных процессов используют 100% ЦП, пока машина не станет полностью неуправляемой.
В настоящее время известен единственный способ решить проблему - вручную перезагрузить поврежденный компьютер. /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. И имейте в виду, возможно, могут быть другие причины, вызывающие 100% -ную ситуацию с ЦП на kswapd, чем описано здесь. Так что автоматическая перезагрузка в этом случае, пожалуй, плохая идея.