Linux чем-то грузится, что полностью перестает отвечать. Как выяснить, чем грузится?

Есть виртуалка Ubuntu 20.04. на машине 2 ЦПУ и 4 Гб оперативной памяти (было 0 Гб swap -- я добавил 8 Гб swap -- об этом ниже).
На ней запущен pm2, nginx, mysql, phpmyadmin.
Работает сайтец небольшой, на который никто не заходит -- ведется разработка сайта.

Иногда (нет строгой периодичности: раз в 3 дня, раз в неделю -- это точно) машина перестает отвечать на все внешние подключения: ssh не подключается, по ip не пингуется, сайт не открывается.

Заббикс говорит, что на машине грузится процессор под 100% и память RAM под 100%.
Я добавил к машине 8 Гб swap -- до этого было только 4 Гб оперативы.

Но это не помогло.

В общем, какие журналы смотреть, чтобы найти причину такого прикола?
Или вообще что делать?

0

htop поставьте, там на первой вкладочке можно отсортировать по CPU, а на второй можно увидеть все IO-активности.

0

Truebin, насколько я знаю, журнала, который бы трекал ЦПУ лоад и куда-то записывал по умолчанию нет. Поэтому можно написать однострочный скрипт с циклом и дампом самых прожорливых процессов в файл и разумный sleep, чтобы не завалило диск. Ну или добавить чуть логики, чтобы писало в лог, когда потребление превысит определенный порог. Либо использовать существующие инструменты мониторинга типа monit'а.
C zabbix не работал, если он позволяет запускать команды, то можно просто запустить через него top и посмотреть. Если по ссх не пускает.

2

Ну почему? Можно задействовать sysstat и там много вкусного.

1

Спасибо, это верно, да.
htop у меня и установлен.

Да только не пойму я: ну на текущий момент я посмотрю, какие процессы грузят ЦПУ.
А разве можно сказать, что самый прожорливый из этих процессов потом и укладывает систему?

0

Truebin, машина сама по себе слабенькая. Htop просто дает возможность помониторить, возможно, выявить аномально прожорливые процессы. Если ничего не найдется, то ничего поделать и нельзя, имхо.
Более опытные линуксоиды вам уже порекомендовали использовать sysstat:
Добавлено через 1 минуту
Это просто еще один набор для мониторинга - в линуксе, как водится, есть множество альтернатив для многих вещей.

1

Ок, спасибо.
Попробую все рекомендации.

0

Где он стоит по умолчанию?

Добавлено через 1 минуту
Она в итоге что, сама ребутается? Тогда в journalctl можно глянуть причину ребута.

0

эээ...
Я указал систему, которая этим и занимается и имеет такой "журнал который трекает ЦПУ лоад и куда-то записывает по умолчанию".

0

Так они есть, и не одна. Маловероятно, что она уже стоит и можно постфактум посмотреть, что случилось. Так что ну потому что по умолчанию - нет.

0

sysstat по умолчанию как раз и пишет всякую гадость про загрузку ЦПУ, Вы чего? Причём тут стоит/не стоит?

0

_sg2, журналы надо будет смотреть только после того, как он установит утилиту для мониторинга и воспроизведет проблему. Сейчас он никакой информации о том, почему случилась проблема, там не найдет.

0

Нет, она не ребутается.
Просто не пингуется по ip, не открывается сайт с этой машины в браузере, не работает ssh.
Я так понимаю, машина настолько зависает, что все перестает работать.

0

Ну так установит и увидит, в чём проблема-то? Тем более что всё это может и стоит уже.

0

Нашел хорошую статью, как в Заббиксе сделать так, чтобы при критической нагрузке на процессор создавался лог 10-ти первых процессов, которые больше всего нагружают процессор.

https://serveradmin.ru/monitor... -v-zabbix/

Красота. Не надо ничего ждать.

Заглючит машину -- потом просто глянешь список процессов.

0

Кто сказал, что есть проблема? Я ответил на твой вопрос "ну почему?". Если для тебя это проблема, то ничего с этим сделать не могу. Навряд ли.

0

Вы и сказали, вернее и написали.

0

Не, я ни про какую проблему не писал.

0

У меня периодически возникает похожая ситуация на рабочем и домашнем компах с Linux Mint. Возникает в случайные моменты во время сборки кикада из исходников, при этом в момент зависания начинает непрерывно светиться светодиод жесткого диска. Колом комп становится не сразу, несколько секунд просто сильно тормозит (что даже мышь двигается рывками). Если в этот момент успеть закрыть браузер - светодиод успокаивается и торможение пропадает. Если не успеть - комп встает колом и непрерывно дрючит жесткий диск. У меня максимум хватало терпения полчаса ждать, что он успокоится - нет, за полчаса изменений не происходит, приходится жать кнопку сброса. Иногда я успевал нажать Ctrl-Alt-F1, перейти в текстовую консоль, залогиниться и запустить top/iotop. Там показывало, что все отжирает какой-то системный процесс. Часто удавалось переключиться в текстовую консоль, но приглашение ввода имени пользователя появлялось через несколько минут, а пароль не принимался потому что до момента, когда система дойдет до его проверки, истекало время, отведенное на ввод пароля (то есть через минут десять торможения выдавалась ошибка login timeout или что-то такое).

Обычно мой скрипт собирает кикад на двух ядрах из четырех. Сегодня я решил запустить сборку на всех ядрах и комп начал вставать клином каждый раз на компиляции одного и того же файла даже если не запущен ни брузер ни какие-то еще жрущие ОЗУ программы. Поскольку ситуация повторялась, я перед сборкой запустил системный монитор и увидел, что компиляция этого файла сжирает все ОЗУ. В момент, когда использование ОЗУ доходит до 100%, происходит то самое торможение. Собрать кикад удалось только снова запустив сборку на двух ядрах. ОЗУ у меня 8 гиг, под swap зарезервировано 25 гиг (это другая история) и этот swap в момент зависания пустой. Тут я вспомнил, что до перехода на ssd на этих компах я пытался заставить их не трогать swap при свободной половине ОЗУ и поставил vm.swappiness равным нулю. На ноуте ssd стоял "из коробки", там я swappiness не трогал и там зависаний не бывает. Вернул его значение на исходные 60, запустил сборку на всех ядрах снова - сборка прошла без зависаний с открытым браузером, в swap упало 2.8 гига.

Спасибо вам, что подтолкнули меня к решению моей проблемы. Так бесило, когда запустил сборку в фоне, сам пишешь какую-то программу и в самый неподходящий момент - бац, "аааа... я давно не сохранялся, мат-мат-мат". Может быть моя информация поможет и вам найти причину у себя...

1

Dushevny, и вам спасибо за такую историю с подробным описанием.
Очень полезный опыт описали, как по мне.

Но у меня swap задействован, я и не знал, что можно "заставить" машину не трогать swap при каких-то свободных % ОЗУ.
Буду знать.

Век живи -- век учись, как говорится.

0