Apache, mysql. Почему очень много процессов и большое потребление памяти?

Question

[Максим Ходырев]

Сервер на CentOS (8 ядер, 16 Гб RAM), стоит связка nginx + httpd + mysql + memcached.

Команда(количество процессов)
pgrep httpd | wc -l
выдает 88, хотя пользователей на сайте одновременно явно меньше.

Каждый процесс httpd тянет за собой подключение mysql, в итоге память рано или поздно переполняется и сервер падает.

Пару раз случалось, что падал memcached(1.4.15, стоит на том же сервере), есть подозрение что узкое место - mysql и что при падении memcached mysql просто не справляется.



Спецы, как вы думаете, где узкое место и что нужно сделать чтобы избавиться от этого?

Answer 1

[Sergey]

Ну, для начала.
1) Включить server-status (включая Extended) и смотреть.
2) Смотреть логи апача
3) Поставить mytop, смотреть
4) Включить slow log, изучать
5) Поставить atop, iotop, наблюдать

Дальше уже можно ставить newrelic, изучать. Ну и я надеюсь, что какой-то исторический мониторинг есть? Хотя бы munin?

Comments

[Максим Ходырев]

Спасибо за ответ. Из средств мониторинга установлен Munin.

[Максим Ходырев]

Логи апача пестрят ошибками о невозможности подключиться к mysql(падает mysql) и невозможностью занести данные в memcached. Это все во время падений.

[Sergey]

пройдись скриптами
https://launchpadlibrarian.net/78745738/tuning-pri...
и
https://raw.github.com/major/MySQLTuner-perl/maste...
посмотри, может конфиг мускула не соответствует параметрам системы и характеру нагрузки.
Ну и как всегда в подобных вопросах - рекомендую найти и нанять профессионала на помощь.

[Максим Ходырев]

@bondbig насчет профи - дело плохо, нанимали уже. Толку можно сказать null. В итоге как разработчику, работающему на проекте, приходится разбираться мне, а я не силен в администрировании.

[Sergey]

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

[Максим Ходырев]

@bondbig. Нанималось уже 3 человека. Я неверно немного выразился, имелось в виду что настоящего профи найти проблема.

[Sergey]

Да уж, не везет.
Оплату-то хоть по результатам работы осуществляли? Вперед платить нельзя в таких случаях.
Но и насчет "настоящего профи найти проблема" - это горькая правда, почти в любой области сейчас.

[Максим Ходырев]

@bondbig, Насчет оплаты точно не знаю, занимался менеджер. В общем спасибо за наводку на эти инструменты, буду копать.

[Алексей Сундуков]

@maximkou если не секрет, какой порядок бюджета был?

Answer 2

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

Крон ничего не делает в сторону запуска этих процессов?
Посетителей как считаете ? По логам или на глаз? Если считать RPS, а не ненужное число - оно нормальное?
Nginx точно всю статику сам отдаёт? Ничего лишнего в apache не проксируется?
Тумблы какие-нибудь генерятся не апачем, случайно?

Чем вообще процессы заняты? Что в strace ?

Comments

[Максим Ходырев]

Есть задачи на кроне, которые могут запускать процесс апача, но их 3 штуки, и они сильно разнесены по времени.

Посетителей примерно считаю по количеству коннектов на 80 порт(netstat -na | grep :80 | wc -l).

Nginx отдает всю статику.

Тумблы генерятся не апачем.

Насчет процессов не знаю, нужно будет посмотреть.

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

@maximkou
> Есть задачи на кроне, которые могут запускать процесс апача, но их 3 штуки, и они сильно разнесены по времени.
Проверьте, что там ничего лишнего не появилось, и что там нет бесконечных циклов.
Как вариант - к вам затесался скрипт, который в цикле делает кучу чего-либо (письма шлет, например).

> Посетителей примерно считаю по количеству коннектов на 80 порт(netstat -na | grep :80 | wc -l).
Я же писал - посчитайте RPS, а не "ненужное число". Через один keepalive коннект можно сделать пару сотен запросов в секунду. А в nginx keepalive наружу по дефолту включен.
Смотрите сколько запросов в логах.

> Nginx отдает всю статику.
Аналогично, проверяйте - https://debian.pro/328 (история на эту тему).

> Насчет процессов не знаю, нужно будет посмотреть.
С этого вообще и нужно было начинать, чтобы понять, что происходит)