Неприятные пики ЦП, которые не связаны ни с какими видимыми процессами
Действительно странная проблема здесь. Я периодически получаю действительно неприятные пики ЦП, когда ЦП загружается на 80-90% во всех ядрах в течение примерно 5 минут. Когда я смотрю на conky, в htop или системном мониторе и сортирую по% CPU, я не вижу ни одного процесса, который учитывает такое большое использование CPU.
Единственное, что я изменил с тех пор, как это началось:
- Я перешел на версию ядра 2.6.35 (домашняя компиляция, вместо 2.6.24-1)
- Я установил драйвер Nvidia 256.44 (вместо 256.34)
Теперь я хочу понизить любой из них или оба, чтобы найти проблему, но я бы предпочел сделать это как можно более научно и найти выяснить, что является причиной взрыва процессора, прежде чем я понизил.
Редактировать: Моя точная проблема выглядит как регрессия NVIDIA в их последней версии драйвера. Другие люди получают аналогичные шипы .
6 ответов
Это может быть поток ядра, который по умолчанию скрыт в большинстве мониторов производительности. В htop вы можете скрыть / показать потоки ядра с помощью "K" (shift + k).
Я думаю, что это проблема ядра. Я бы вернулся к официально протестированной версии.
Я попытался бы найти причину проблемы с некоторым сценарием оболочки:
#!/bin/sh
MAXLOAD=100
CURRLOAD=`uptime | sed 's@.*load average: \([^,]*\).*@\1@' | sed 's@0\?.0\?@@'`
if [ $CURRLOAD -gt $MAXLOAD ]; then
ps -eo tid,pcpu,comm | sort -n -k 2 | tail -n 5 | \
mail -s "High load" -e your@addre.ss
fi
В сценарии есть две переменные MAXLOAD и CURRLOAD. Первый из них должен быть высокой нагрузкой, умноженной на 100. Поэтому, если вы столкнулись с пиковым значением и видите, что нагрузка на систему возрастает до 2 или 3, то вы должны установить MAXLOAD на какое-то значение около 200. $CURRLOAD принимает вывод uptime, ищет нагрузку и удаляет точку, а также ведущие нули.
Если нагрузка в какой-то момент слишком высока, она распечатывает пять процессов с наибольшей загрузкой ЦП и отправляет их в your@addre.ss.
Этот скрипт должен помочь вам найти причину всплеска, и, если вы знаете это, вы, возможно, сможете решить вашу проблему.
Есть некоторые недавно исправленные ошибки, которые могут исправить эту проблему. Если вы работаете в Ubuntu, я бы предложил использовать ядро Ubuntu, чтобы получать исправления через регулярные обновления. Я бы рекомендовал установить Lucid для поддержки и стабильности. Вы можете пойти с Maverick, если есть функции, о которых вы знаете, которых нет в Lucid, которые вам нужны.
Чтобы получить вывод из top, который вы можете сохранить: top -b -n1
Вставьте это в cronjob, и вы сможете посмотреть на мелкий список процессов даже после того, как проблема исчезнет. Пример записи в crontab:
* * * * * top -b -n1 > /tmp/top_output_$(date +%Y-%m-%d_%H:%M:%S)
Это сохранит его в одном файле в минуту в / tmp
«Процессор загружается на 80-90% во всех ядрах в течение примерно 5 минут»
Такое интенсивное использование позволит вам точно определить виновника с помощью pidstat, доступного в пакете sysstat.
Просто запустите pidstat -u | sort -nr -k 7,7 | head -10, и процесс, который использовал больше всего ЦП, должен быть в верхней строке.