Как определить, кто устроил высокий local timer interrupts?

0

2

Сегодня с утра офигенно подскочил уровень Local timer interrupts. С обычных нескольких тысяч в секунду до 70-80 тыс. Также подскочило число форков с нескольких десятков в секунду до 700. Я так понимаю, что какой-то процесс/процессы стали вылетать/запускаться в бесконечном цикле. Но что это — х.з., по top/atop/ntop/etc не отловить. Есть мысли, как поймать, что там постоянно форкается?

Ссылка

←	Температура процессора и видеокарты

Объединить 2 таблицы: как сделать FULL OUTER JOIN стандартными средствами

→

Придумал так:

watch "ps aux | grep `date +%H:%M`"

Вижу постоянно скачущие /lib/systemd/systemd-udevd --daemon, не в них ли дело?

Ubuntu 14.04, где systemd ещё не полноценный, не знаю, где посмотреть, чем он занимается. В syslog пусто, journalctl нет.

~~KRoN73~~ ★★★★★
(13.11.16 14:35:40 MSK) автор топика

Ответ на: комментарий от KRoN73 13.11.16 14:35:40 MSK

Нет, это что-то разовое было. И, вероятно, из контейнера. Устаканилось, forks/sec по-прежнему огромный, но процессов, запущенных в текущую минуту не видно.

Every 2,0s: ps aux | grep 14:38                                                                                                        Sun Nov 13 14:39:37 2016

root      3571  0.0  0.0      0     0 ?        S    14:38   0:00 [kworker/0:2]
root      6910  0.0  0.0      0     0 ?        S    14:38   0:00 [kworker/u16:3]
root     21749  0.0  0.0  15504   760 pts/12   S+   14:39   0:00 watch ps aux | grep 14:38
root     21750  0.0  0.0   4440   640 pts/12   S+   14:39   0:00 sh -c ps aux | grep 14:38
root     21753  0.0  0.0  12964   908 pts/12   S+   14:39   0:00 grep 14:38
root     23050  0.0  0.0  15508  1908 pts/12   S+   14:38   0:00 watch ps aux | grep 14:38
root     23238  0.0  0.0      0     0 ?        S    14:38   0:00 [kworker/3:2]
root     28499  0.0  0.0      0     0 ?        S    14:38   0:00 [kworker/4:3]

~~KRoN73~~ ★★★★★
(13.11.16 14:41:30 MSK) автор топика

Ссылка

Как это вычислить я так и не нашёл, но «вручную» нашёл проблему — зазомбифицировался ipfs-демон, а «пускалка» этого не понимала и пыталась в бесконечном цикле его рестартовать.

Теперь ломаю голову, как убить зомби, не перезапуская сервер :)

~~KRoN73~~ ★★★★★
(13.11.16 14:48:15 MSK) автор топика

Ответ на: комментарий от KRoN73 13.11.16 14:48:15 MSK

Всё, раззомбировался сам :)

Но непонятно, как решать сабжевую проблему, если бы я не нашёл проблему вручную.

~~KRoN73~~ ★★★★★
(13.11.16 14:50:10 MSK) автор топика

Ссылка

Ответ на: комментарий от KRoN73 13.11.16 14:48:15 MSK

Зомби не убить. Просто выкинь systemd, 100% дело в нём.

anonymous
(13.11.16 14:53:09 MSK)

Ссылка

systemd (232-2) unstable; urgency=medium

  * Drop RestrictAddressFamilies from service files.
    RestrictAddressFamilies= is broken on 32bit architectures and causes
    various services to fail with a timeout, including
    systemd-udevd.service.
    While this might actually be a libseccomp issue, remove this option for
    now until a proper solution is found. (Closes: #843160)

 -- Michael Biebl <biebl@debian.org>  Sat, 05 Nov 2016 22:43:27 +0100

Оно?

qnikst ★★★★★
(13.11.16 19:03:48 MSK)
Последнее исправление: qnikst 13.11.16 19:04:03 MSK (всего исправлений: 1)