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

Этот сбил меня с толку. У меня Ubuntu 14.04, 3 дня назад (2014-20-10) он начал тормозить.

Я воспроизвел его, открыв gedit, а затем закрыв gedit. Когда проблема активна, она закрывает пустой файл примерно на 2 секунды, в то время как без проблемы это всегда происходит мгновенно - все остальное действует аналогичным образом.

top сообщает, что нет никакой необычной активности, когда происходит замораживание, но то же самое, и то же самое.

Эта проблема возникает только после 30 минут безотказной работы. Я могу гарантировать, что при 29 минутах безотказной работы я не смог воспроизвести ее, при 31 минуте безотказной работы я мог воспроизвести это последовательно (с использованием вышеуказанного метода, никакие приложения не запускались, кроме терминала и htop) и управлял повторить это 4 или 5 раз (выключение, загрузка и ожидание полчаса - что было приятно).

Проблема сохраняется даже после перезагрузки, но может быть сброшена путем выключения и включения питания. Какая часть Ubuntu сохраняет состояние после перезагрузки, но не выключается?

Соответствующими журналами для этого периода являются syslog, 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 apt-get' - нет установок в этот период времени
• Посмотрел историю синаптического менеджера пакетов - ничего за тот период времени
• История центра программного обеспечения - последнее обновление было несколько недель назад (возникла проблема с зависимостью, поэтому я не делал никаких обновлений некоторое время)
• Я установил Skype для Ubuntu примерно в это время, но нет никаких признаков того, что он вызван Skype (все равно удалил)

Cron работа идет не так

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

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

Вредоносное

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

Другие вещи, которые я пробовал:

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

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