Сервер как по расписанию в 10 мск и 22 мск заваливается с LA>50. Куда копать?

Question

[NightWriter]

Идей никаких, траффик не набегает в эти периоды, кронтаб посмотрел. Все остальное время – идеально работает. Просто не понимаю, что происходит, может, кто что подскажет?

Comments

[VBart]

Сервер физический или виртуальный?

[NightWriter]

физический, 6 ядер, 64 оперативной, sata-диски в raid 1

Answer 1

[Влад Животнев]

50+ LA — это средняя температура по больнице. У меня одна из тушек под боевой нагрузкой стоит в 1300 la и радостно всем отвечает.

А вот если у вас wa больше 5-10% — копайте в сторону тормозящих дисков или сети. Ну и другого IO, если он там есть.

Comments

[Влад Животнев]

Ну да, 1300+ мелких процессов. Чего ж тут ненормального?

[nochkin]

LA это не количество процессов, LA — это загруженность сервера (можно посмотреть командой «uptime», там будут три цифры в конце строчки).

[Влад Животнев]

nochkin, вам бы школьникам это объяснять, может чего и вышло. LA от его названия не становится «загруженностью сервера». Это среднее количество процессов за 1,5,15 минут, которые находились в очереди за ресурсами (cpu/IO). Эта очередь может расти до бесконечности, если правильно играться приоритетами процессов. Если вы запустите с минимальным приоритетом 50к процессов (и нужное количество процессов с высоким приоритетом, чтобы забить CPU) — то la вполне себе может вырасти до 50к и серверу будет на это наплевать.
Более того, если вы сделаете cgroups контейнер с лимитом в 1 mhz, например, и запустите в нём 50к процессов — то получите ровно то же самое.

Поэтому la — ничто иное, как средняя температура по больнице. Сигнал, что что-то случилось, но далеко не всегда говорящий о том, что случилось что-то плохое (или вообще то, на что стоит обратить внимание).

А сам loadvg правильно смотреть в /proc/loadavg. И удобнее.

Answer 2

[Влад Животнев]

/var/spool/cron/crontabs/* ещё посмотрите, если уж на крон грешите.

Answer 3

[nochkin]

А в логах что? Чистый reboot или что-то реально грохнулось?
Если всё равно непонятно, то можно попробовать прямо перед часом X уложить все процессы вручную и посмотреть если чистая система перезагрузится сама по себе.

А так похоже на какой-то maintenance скрипт.

Comments

[NightWriter]

Он не ребутится, он вываливается в космический LA, сегодня было 88. Заваливается я имел в виду – перестает полностью быть доступным

[nochkin]

LA — это Load Average? У меня сразу критическая перезагрузка на слово «заваливается».
Тогда да, надо смотреть что начинается крутиться в этот момент. Если слишком быстро и непонятно, то можно попробовать, всё-таки, убить на время что-то тяжёлое и посмотреть если оно как-то влияет.
Что там вообще из тяжёлого на сервере крутится что может так сожрать ресурсы? Какая примерная конфигурация сервера (сколько ядер, памяти, публичный ли сервер и т.п.)?

[NightWriter]

Да, load average. Крутится обычный сайт на php (nginx+apache+mysql), ничего военного, все остальное время страницы бодро генерируются за 200-300 миллисекунд, кэши есть, eaccelerator стоит

[nochkin]

Я так понял что сервер публичный. А что за конфигурация? Сколько памяти, ядер, какие диски, например?
Максимальный нормальный LA на разных конфигурация разный.

mysql может хорошо слопать ресурсов при небольших изменениях конфигов.
Можно ради интереса отключить на тот момент nginx что бы понять из внешнего мира приходить козявка или нет.

[NightWriter]

64 гига памяти, 6 ядер, и7, диски sata raid 1. mysql тюненый, но память не всю выедает даже в таких ситуациях

[nochkin]

Сколько может слопать mysql можно примерно оценить с помощью скрипта mysqltuner.pl.
Тогда надо следить за потреблением прямо перед тормозами или попробовать отключить внешний мир на несколько минут что бы понять откуда вообще влияние идет — изнутри или снаружи.

Answer 4

[NightWriter]

При этих 50+ вообще веб-сервер не отвечает и консоль даже тормозит. Это сколько у вас процессоров, то 1300 – это ок?

Comments

[Влад Животнев]

Первая строка — троллинг. LA — просто кол-во процессов, которые ждали ресурсов — не только cpu. Суть во второй строке.

Запускайте atop в режиме демона и смотрите потом, какой процесс кушал диски/сеть в указанное время.

[Эргил Осин]

Да-да, atop, с записью раз в 60 секунд или чаще, а не с дефолтными 600, как идет в Debian/Ubuntu и потом читать.

Answer 5

[Daniel Newman]

Предположу что это как-то может быть связано с бэкапом. Чисто теоретически.
Начните с /etc/cron.d или где там у вас крон?

Comments

[NightWriter]

хорошая идея, но он в 12 ночи, крон пуст почти, началось недавно и я перед этим в крон не писал ничего

[NightWriter]

Лог крона что-то вообще не нахожу (

Answer 6

[TeiSinTai]

А статус и логи рэйд-контроллера смотрели? Мб он именно в это время verify делает. Я так подозреваю, что снижение отзывчивости дисков это даст спокойно.

Comments

[NightWriter]

а это куда смотреть?

[TeiSinTai]

Ну это от модели контроллера зависит. Для 3ware под линух есть tw_cli, консольная утилита управления. Для LSI вроде тоже что-то было… Надо смотреть утилиту производителя под линукс — если есть. Если нет — тогда всё сложно. Может быть, лог можно прочитать, зайдя во встроенную утилиту при загрузке сервера — если есть KVM или физический доступ — и если контроллер показывает там лог. Ещё вариант — изоляция проблемы — перед часом «Ч» заблокировать через iptables сетевой доступ ко всем портам со всех адресов, кроме своего управляющего, погасить на сервере все сервисы, оставить только sshd, и запустить копирование диска в /dev/null. Если в час «Ч» он-таки поднимет LA — да, скорее всего какие-то задачи по расписанию у raid-контроллера.
Вообще, напишите модель контроллера, может у кого-то такой же стоит.