Этот экранировал меня. У меня есть Ubuntu 14.04, 3 несколько дней назад (2014-20-10), она начала замедляться.
Я воспроизвел его путем открытия gedit и затем закрытия gedit, когда проблема активна, это поражает примерно 2 секунды для закрытия пустого файла, пока без проблемы это всегда мгновенно - влияет на все остальное подобным образом.
вершина не сообщает ни о каком необычном действии, когда замораживание происходит, htop то же, iotop то же также.
Проблема только возникает после 30 минут времени работы я могу гарантировать, что в 29 минут времени работы не мог воспроизвести ее в 31 минуту времени работы, я мог последовательно воспроизводить это (использующий выше метода, никаких приложений, запущенных кроме терминала и htop) и управляемый для повторения этого 4 или 5 раз (путем закрытия, начальной загрузки и ожидания получаса - который был приятен).
Проблема сохраняется даже после перезагрузок, но может быть сброшена путем закрытия и включения назад, какая часть Ubuntu содержит состояние после перезагрузок, но не завершений работы?
Соответствующие журналы в течение этого периода являются системным журналом, auth.log и Xorg.0.log (путем исследования содержания/var/log в течение времени, измененного в указанном диапазоне)
системный журнал:
Oct 22 17:21:36 raiden NetworkManager[1102]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Oct 22 17:39:01 raiden CRON[3284]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Oct 22 18:09:01 raiden CRON[3370]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
authlog:
Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session closed for user root
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session closed for user root
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session closed for user root
Xorg.0.log: (вероятно, я просто просыпающийся компьютер назад)
[ 3466.727] (II) intel(0): switch to mode 1366x768@60.0 on LVDS1 using pipe 0, position (0, 900), rotation normal, reflection none
[ 3466.880] (II) intel(0): switch to mode 1600x900@60.0 on VGA1 using pipe 1, position (0, 0), rotation normal, reflection none
Ни один из тех ни на что не указывает плохо, и последующие шаги для репродуцирования проблемы не указывают ни на какие изменения в журналах, таким образом, они были наиболее вероятными просто невинные журналы.
Я предполагаю, что существует 3 возможных источника этой проблемы:
Установка программного обеспечения: Я установил что-то изворотливое
Я сделал:
Задание крона, идущее не так, как надо
Проверенный cronjobs в crontab,/etc/cron.d/etc/cron.daily и каждый час ничем указывающем это - что-то там, что только задание крона PHP происходит каждые 30 минут, но если бы это был крон, то он сделал бы это в определенные моменты круглосуточно не спустя 30 минут после запуска.
Анализ новых процессов, которые были запущены между состоянием незамедления и состоянием замедления, предполагает, что никакие новые процессы не запускаются, (сначала тестируют, это разоблачило поток kworker, но это, вероятно, просто будет совпадением). Я предполагаю, что это должно означать, что это - или существующий процесс, который инициировал его или что-то еще.
Вредоносное программное обеспечение
Из-за он неуловим, и таинственные 30 минимальных отсутствий проблемы (30 минут походит на выбранное человеком количество времени), я начал думать, что это могло быть некоторое вредоносное программное обеспечение однако вряд ли, это могло быть (не сделал обновления некоторое время и имеют несколько открытых портов). Так выполнил rkhunter (средство поиска руткита), но ничто неблагоприятное не было найдено.
Другие вещи я попробовал:
Имеет любого, имел что-либо подобное этому, происходят с ними или мог указать на меня в правильном направлении, если Вы сделаете то я буду совершать нападки кнопка голосования неоднократно на Вашем ответе (я удостоверюсь, что это - нечетное число),
Это было вызвано УМНЫЕ данные включаемый для рассматриваемого диска.
Отключающие УМНЫЕ данные решили это:
sudo smartctl --smart=off /dev/sda
, По-видимому, это продолжало повторно выполнять некоторую внутреннюю самопроверку спустя 30 минут после диска, который вращают, и вошло в цикл; поскольку это было в аппаратной остальной части слоя компьютера, не знал, что он продолжился следовательно, я не видел процесса, в особенности ответственного за блокирование IO и никакие процессы hogging ресурсы.
Существуют некоторые способы настроить крон для выполнения задания спустя 30 минут после запуска. Jenkins делает это путем хеширования функции и использования H/30 * * * *
, например. Это мог также быть поток, спящий в течение 30 минут и порождающий тихий уничтожающий процесс CPU.
Некоторые идеи там:
Вы пробовали htop как корень? Некоторые процессы могут быть невидимыми, я видел это на Debian особенно.
Вы пытались выйти из системы / входят в том, когда проблема происходит? Мог быть менеджер окон или проблема сессии.
, Если выход из системы/вход в систему не работает, можно попытаться перезапустить менеджер сеансов. Я думаю, что это - lightdm по умолчанию, таким образом sudo service lightdm restart
должен сделать это.