Почему apache создаёт много процессов, что в итоге роняет систему?
Всем доброго времени суток.
Есть веб сервер zabbix 3.0 на виртуальной машине под управлением Debian 3.2.0-4-amd64 (vmware 12 ядер 8 гб оперативы). На нём:
NGINX - frontend, Apache - backend, php5. Mysql на другой физической машине
Нагрузка на серв достаточно большая. В заббиксе огромное множество карт с тысячами элементов (думаю основная проблема именно в них). Пользователей одновременно может работать в районе 100.
Ситуация следующая. Относительно недавно веб сервер стал тормозить. Плодятся процессы "/usr/sbin/apache -k start". Постоянно. Не зависимо от времени суток и соответсвенно загруженности сервера.
Плодятся они до того момента пока не кончиться память и сервер не перестаёт отвечать.
Ребутаем апач - всё отлично и шустро работает. Сервисы начинают плодиться, но всё равно всё быстро и шустро работает. Проходит 10 минут, сервисов становится 25, проц загружен на 100% (все ядра по 100), но всё равно веба отвечает достаточно быстро.
Проходит 20 минут, сервисов уже штук 40, но нам пофиг, у нас всё работает круто
Проходит 30 минут, сервисов уже штук 60, мы еще терпим, памяти съедает гигов 5-6, но уже начинаются задержки.
Проходит 50 минут, сервисов уже штук 80, мы не выдерживаем и ощущая реальные тормоза отправляем апач в ребут.
Дальше всё по кругу. Не важно в какое время, в рабочее или глубокой ночью. Примерно в течении часа сервер помирает.
В apache2 error.log начинает ругаться только когда переполняется память и серв не может больше плодить процессы. В других логах так же вроде как чисто.
Я запарился с этим биться уже. Прошу советы в стиле "переустанови виндовс" не давать. Это будет уже самая крайняя стадия, пока что важно найти корень зла, а не вырубать весь лес.
Хочу так же добавить, что раньше был просто nginx + php5-fpm и ситуация была точно такая же, только пладились процессы php5-fpm. (это было хуже, потому что при загрузке в 100% всех ядер работать было не возможно, а при текущей ситуации, плодовитость процессов на скорость работы практически не влияет, пока они не сожрут всю память).
Скажу еще главную фразу: "раньше всё работало отлично в течении нескольких месяцев. никакие настройки я не менял и оно само"
Для начала понять, что больше всего запрашивают пользователи, т.е. что наиболее востребовано. Затем профилировать работу этой части заббикса: понять что именно наиболее ресурсоемко. Количество процессов плодится потому, что запросы слишком долго обслуживаются. Первое, на что бы я грешил - связка php + mysql, особенно учитывая, что последняя на отдельной физической машине. Запускайте какой-нибудь xdebug, изучайте что и где тормозит. Включайте кэширование везде, где это возможно.
что наиболее востребовано
что именно наиболее ресурсоемко
Скрипт /usr/share/zabbix/map.php - к нему очень часто обращаются. Это карты, на картах разные наши сети, вся инфа по этим сетям. Пользователи очень часто сидят и тупо "дрочат" эти карты.
php + mysql, особенно учитывая, что последняя на отдельной физической машине.
Между серваками 10гб сеть.
Сервер мускуля совершенно не загружен (htop "зелененький. Памяти свободно 40 гигов). Слоу лог пока включить не могу, сделаю ночью и гляну (забываю про него постоянно). Да и честно сказать думаю что мускуль не причём. Я сделал клон этого вебсервера с запросами на этот же самый мускуль и пересадил часть пользователей на него (чтобы разгрузить основу). Это не помогло.
Я грешу на php, но не переписывать же мне скрипты забикса в ручную ? .... да я и не смогу :(
Виталий Р, возможно вечером появляется пользователь (или пользователи), который начинает грузить систему каким-то особым запросом? Теже карты, но какая-то особая выборка. В эту сторону получится подумать?
Dmitry Tallmange, Это один из первых вариантов которые мы рассматривали. Пытались отключать пользователей по сетевым сегментам. На самом деле, очень похоже именно на это, но к сожалению конкретно и точно отследить никак не получиться, да и некоторые моменты всё таки создают сомнения. Например то, что нагрузка может пропасть с двух ночи до трех, а потом с трех до пяти появиться. Ну вряд ли кто-то работает и главное, нагружает сервак в 5 утра, потом с 5 до 6 перестает работать, а в 7 утра начинает снова.
1. количество процессов которое допустимо описывается в конфиге апача (ищи worker) тоже самое и касается php-fpm, вывод надо открыть конфиг и указать максимальное количество обработчиков.
2. на забикс приходит обновление с различных устройств может быть стоит их не так часто отправлять и посмотреть конфиги забикса а также настройки по сбору обновлений ? потому ему может банально шлют слишком много данных которые он не в силах обработать и тут решение или уменьшать количество данных, или масштабировать сервер (вертикально или горизонтально)
Как только я не игрался с этими значениями. Честно говоря ни к чему особому это не привело. Хотя скорее всего я просто уже туплю, поэтому в итоге оставил всё как последний раз изменил и забил.
на забикс приходит обновление с различных устройств может быть стоит их не так часто отправлять
Данных и вправду шлют просто нереально много. У нас одних только узлов 11 тысяч. Есть прокси сервер на одном большом сегменте. Попробую покопать в сторону уменьшения частоты опросов.
Подскажите пожалуйста, как расчитать значения в данных конфигах исходя из следующего:
Пользователей одновременно у нас примерно 100 штук. Из них штук 80 просто просмотр (в основном тяжелые карты) 20 могут что-то настраивать, но редко все вместе настраивают.
Элементов данных 80 тысяч
Количество узлов 11 тысяч
Виталий Р, нет универсальных показателей где количество людей умножить на показатель на пользователя,везде профили нагрузки разные
раз при 80 процессах не выдерживаете надо понять что является бутолочным горлышком (скорей всего бд и операции ввода вывода)
оптимизация производительности делается каждый раз индивидуально
вам надо масштабироваться и лучше это делать горизонтально подкчючать новые сервера для обработки данных и балансировать нагрузку это не просто процес и его в одном коменте не объяснишь начинать путь отсюда https://nginx.ru/ru/docs/http/ngx_http_upstream_mo...
я бы сделал следующее
1. Нашел бы в чем именно проблема(собрал бы показатели по нагрузке io, cpu, ram также собрал бы эти данные с серверов бд)
2. По возможности запросил бы еще сервера (вынес бд отдельно, 1 фронт сервер на nginx и группа серверов через upstream для обработки запросов)
3. Посмотрел бы какие сервера тормозят, будет тормозить или бд или backend сервера (или и то и другое)
4 Начал бы оптимизацию бэкенд серверов начал бы банальных php opcache (потому что банально интерпретировать файлы дорого для cpu) искал бы узкие места и оптимизировал их
4.2 читал бы про zabbix и про оптимизацию его под нагрузку
5.Для бд смотрел бы медленные запросы, использовал бы кэш и тд, всячески уменьшал бы нагрузку на io, шардинг и тд
Для выполнения этих действий нужны квалифицированные люди, можно пытаться ограничить на nginx количество запросов к бэкендам и тогда лишние будут получать ошибки, что не очень.
Вот не поверите, но всё это по каждому пунктику уже сделано и неоднократно. В начале был nginx + phpfpm и тупил именно php-fpm грузил проц на 100%. Я всё что мог тогда собрал (тут на тостере есть отдельная тема по этому поводу) в итоге пришли к мнению, что надо обновить забикс. Я люблю разбираться в проблеме до конца и редко прибегаю к методам "всё снести и поставить снова".
Решил проверить как будет работать веб, без phpfpm. Сделал апач бэкендом. Тоже самое, только теперь плодятся apache процессы.
Сервер баз мониторю так же постоянно, там нагрузка на проц и 20% в сумме не сотовляет, а памяти из 64гигов доступных хавает только 11.
Как уже писал, сделал клон основного веба и перекинул на него группу пользователей. На нём всё чётко и круто работает. Из 100 пользователей на нём минимум 20-30 сейчас и у них всё круто.
На основном без изменений. Апачи плодятся, серв померает. Пока закинул в крон рестарт апача. Пользователи всё равно не замечают и поидее проблемы нет. Но мы то с вами знаем.... От этого кастыля надо будет избавляться. Вот от безысходности пишу сюда. Я плоховато шарю в веб серверах )))
Я все таки поглубже поразбираюсь с сервером бд. Я не включил там slow.log потому что надо будет его ребутнуть, а он это очень не любит. Но видимо пришло время :)
если нагрузка на cpu и перекинули часть пользователей туда
оборудование в вашей сети в основном стучиться на старый сервер и его обработкой занимается старый сервер, поэтому надо мерить не только по пользователям но и по хостам откуда приходит информация от клиентов, это во первых.
во вторых я бы использовал php-fpm вместо apache+mod_php (это чисто имхо, но совсем не обязательно уверен что apache+mod_php тоже настроить можно просто я чаще настрайваю php-fpm).
в третих в php могут быть установленны всякие xdebug или не включены opcache что может вызывать нагрузку на cpu поэтому не плохо phpinfo приложить по текущему, а также сравнить его с тем где запускали и проблем не было.
в четвертых надо посмотреть сколько rps приходит на балансировщик (nginx) и сколько он прокидывает дальше в backend и нужно понять процессы может быть плодятся кривым скриптом или это реальная нагрузка на сервер
в пятых я бы просто в nginx сделал бы upstream и добавил бы 2 сервера если нагрузка в целом стихла, значит просто ваш сервер не справлялся с ней, если оба сервера стали тормозить значит они не справляются(и тут надо или еще втыкать серваки или уменьшать нагрузку, собирать по реже данные например), если тормозит все тот же сервер а другой работает без проблем то проблема в сервере, после добавления серверов и round robin балансировки нагрузка на двух серверах должна стать примерно одинаковой.
в 6 возможно косяк в коде и где то бесконечный цикл надо понять воркеры зависают или просто большое количество клиентов
в 7 на серверах бд и на других серверах надо мониторить io (ввод/вывод) потому что обычно тормоза идут именно от туда, а не только cpu и ram
Средний
Сложный
Средний
