Потеря производительности после 30 минут

Этот экранировал меня. У меня есть 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 возможных источника этой проблемы:

Установка программного обеспечения: Я установил что-то изворотливое

Я сделал:

  • история | grep склонный - добирается' - никакие установки в тот период времени
  • Посмотревший синаптическая история диспетчера пакетов - ничто в тот период времени
  • История центра программного обеспечения - последнее обновление было за несколько недель до этого (была проблема зависимости, таким образом, я не выполнил ни в каких обновлениях некоторое время),
  • Я установил Skype для Ubuntu около того периода времени, но нет никакого признака, это вызывается Skype (удалил его так или иначе),

Задание крона, идущее не так, как надо

Проверенный cronjobs в crontab,/etc/cron.d/etc/cron.daily и каждый час ничем указывающем это - что-то там, что только задание крона PHP происходит каждые 30 минут, но если бы это был крон, то он сделал бы это в определенные моменты круглосуточно не спустя 30 минут после запуска.

Анализ новых процессов, которые были запущены между состоянием незамедления и состоянием замедления, предполагает, что никакие новые процессы не запускаются, (сначала тестируют, это разоблачило поток kworker, но это, вероятно, просто будет совпадением). Я предполагаю, что это должно означать, что это - или существующий процесс, который инициировал его или что-то еще.

Вредоносное программное обеспечение

Из-за он неуловим, и таинственные 30 минимальных отсутствий проблемы (30 минут походит на выбранное человеком количество времени), я начал думать, что это могло быть некоторое вредоносное программное обеспечение однако вряд ли, это могло быть (не сделал обновления некоторое время и имеют несколько открытых портов). Так выполнил rkhunter (средство поиска руткита), но ничто неблагоприятное не было найдено.

Другие вещи я попробовал:

  • Удаление галочки у определенных compiz компонентов - никакое изменение
  • Перезапуск compiz - никакое изменение
  • Удаление галочки у всех compiz компонентов - никакое изменение (за исключением меня борющийся для получения компьютер, применимый снова)
  • Играя на различных музыкальных инструментах при ожидании в течение времени работы для получения до 30 минут и затем наблюдении результатов вершины и htop для любых подозрительных изменений - ничто нечетное

Имеет любого, имел что-либо подобное этому, происходят с ними или мог указать на меня в правильном направлении, если Вы сделаете то я буду совершать нападки кнопка голосования неоднократно на Вашем ответе (я удостоверюсь, что это - нечетное число),

3
задан 23 October 2014 в 23:52

2 ответа

Это было вызвано УМНЫЕ данные включаемый для рассматриваемого диска.

Отключающие УМНЫЕ данные решили это:

sudo smartctl --smart=off /dev/sda

, По-видимому, это продолжало повторно выполнять некоторую внутреннюю самопроверку спустя 30 минут после диска, который вращают, и вошло в цикл; поскольку это было в аппаратной остальной части слоя компьютера, не знал, что он продолжился следовательно, я не видел процесса, в особенности ответственного за блокирование IO и никакие процессы hogging ресурсы.

0
ответ дан 18 November 2019 в 05:40

Существуют некоторые способы настроить крон для выполнения задания спустя 30 минут после запуска. Jenkins делает это путем хеширования функции и использования H/30 * * * *, например. Это мог также быть поток, спящий в течение 30 минут и порождающий тихий уничтожающий процесс CPU.

Некоторые идеи там:

Вы пробовали htop как корень? Некоторые процессы могут быть невидимыми, я видел это на Debian особенно.

Вы пытались выйти из системы / входят в том, когда проблема происходит? Мог быть менеджер окон или проблема сессии.

, Если выход из системы/вход в систему не работает, можно попытаться перезапустить менеджер сеансов. Я думаю, что это - lightdm по умолчанию, таким образом sudo service lightdm restart должен сделать это.

1
ответ дан 18 November 2019 в 05:40

Другие вопросы по тегам:

Похожие вопросы: