Господа, может подскажите, куда копать. Есть бэк на Ларе (nginx +

php-fpm), который коннектится с Постгресс базой на другом сервере и делает запросы к другому внутреннему Апи, из которого тоже получает данные.
Вчера в один прекрасный момент PHP начал висеть.

Стал разбираться - количество соединений с базой стало превышать 100 и пошли ошибки в Постгресс базе:
FATAL: terminating connection due to administrator command

увеличил лимит соединений до 300, лог ошибок БД перестал заполняться, но PHP не полегчало

в логе php-fpm сегодня пошли ошибки вида
server reached pm.max_children setting (50), consider raising it

пробовал увеличить pm.max_children setting до 100 - не помогло

в логе nginx'а на все эти вещи ошибки
upstream timed out (110: Connection timed out) while reading response header from upstream

По access-логам nginx'а посмотрел количество запросов - в момент когда база упала всплеска запросов нет.

Попробовал посмотреть как выполниться файлик с кодом <?php echo 'ok'; - он то миллисекунд обрабатывается, до 20+ секунд.

Насколько я понимаю, бэк на Ларе где то стал медленно работать, и вешать таким образом весь PHP-код?
Бэк на двух серверах, а перед ними ещё балансер стоит, но вряд ли дело в балансере, т.к. картинки в любом случае быстро отдаются, а PHP висит.

может DOS атака просто?

в access-логе же количество запросов бы выросло? А оно в тот час и потом больше не стало(

лимиты расставляй на соединения (timeout и connect_timeout), с базой, со сторонним API так вообще обязательно и тогда уже сможешь понять где проблема

Да, добавлю. Логгировались только ответы от внутреннего апи, а оно после апдейта стало подтормаживать. В итоге запросы которые отрабатывались за миллисекунды-секунду стали висеть в ожидании ответа до 60 секунд, держа коннекты с постгресс базой. Видимо поэтому 100 коннэктов перестало хватать. Увеличение лимита соединений показало другое слабое место - количество php-fpm процессов в 50. Увеличение до 100 проблему не решило, но с таким лимитом в логе появились таймауты запросов уже к внутреннему апи.

Да, конечно

Запррсы в базу нормально работают, если не с приложения слать ?

К постгрессу у меня есть доступ - открыл логи увидел проблемы, а к внутреннему апи только курл. По итогу тюнинга пыхи начали висеть уже курл-запросы из консоли. Да и без тюнинга подвисали, просто до админов сразу не достучался - думал они что то делают.

Я к тому, что надо выяснить на каком участке затык ) Может условно у тебя код получает данные не только от базы, а от какого то внешнего сервиса, типо рэдиса или по апи вообще с другого ресурса и там проблема, а ты по таймауту не рвешл соединение...но все таки наверное тогда в базе проблема и в пыху лезть пока рано

Потыкайте курлом в апишку примерно в такой конструкции: curl -s --connect-timeout 5 -w "time_namelookup: %{time_namelookup}, time_connect: %{time_connect}, time_appconnect: %{time_appconnect}, time_pretransfer: %{time_pretransfer}, time_redirect: %{time_redirect}, time_starttransfer: %{time_starttransfer}, time_total: %{time_total}\n" -o /dev/null `https://example.com`

И скиньте вывод)

Да, именно так и делал и увидел проблемы в ней) Просто админы апи перед этим сказали у нас проблем нет. Оказалось всё-таки есть (

А что именно грустит? Резолв имени?

Внутреннее апи подвисает.

Куб?) k8s

Нет.

Эх.. Не на докере крутит аппликуху свою?

Этого уже не знаю, оно ещё дальше взаимодействует с другой внутренней инфраструктурой. Да и подвисать стали разные запросы к этому апи, поэтому тоже не сразу понял в чем дело.

Просто если в контейнере на альпине крутится, то welcome to hell. Там просто прекраснейше испоганена сеть.

Нет)

Ну тогда пинайте админов, что то резко простое в голову не идёт)