Laravel + PHP FPM + MYSQL Проблема: «Невозможно назначить адрес» при большой нагрузке ⇐ Php

[Anonymous]

У нас есть 3 капли цифрового океана Ubuntu (*исключая интерфейс nextjs):
BACKEND:
16 виртуальных процессоров | 32 ГБ оперативной памяти
БД MYSQL:
8 виртуальных процессоров | 16 ГБ оперативной памяти
REDIS:
4 виртуальных процессора | 32 ГБ оперативной памяти

• Мы используем laravel -> через php-fpm -> за nginx
• У нас установлены драйверы сеанса и вещания на REDIS.
• Мы используем IP-адреса серверов для подключения как к MYSQL, так и к REDIS (без tls)

У нас есть веб-сайт, на котором время от времени появляется большое количество одновременных пользователей.
Нагрузка будет мгновенно прыгать с 0 до 90, но он прекрасно с этим справляется, если не считать ограничений конфигурации системы, с которыми мы сталкиваемся на каждом этапе пути.
За неделю отладки проблем мы сделали следующее, устранив узкое место и перейдя к следующему:

• Мы начали использовать opcache
• Мы установили php-fpm в статический режим с максимальным количеством подключений, равным 2000, поэтому у нас есть процессы со скоростью 2000 кадров в минуту, ожидающие обработки запросов (процесс перезапустить после выполнения 1000 запросов)
• Мы столкнулись с проблемой с рабочими подключениями NGINX, когда их было мало и запросы отбрасывались, поэтому мы увеличили это значение равно 7500
• Затем мы столкнулись с проблемой с ограничением nofile и установили его на 50_000
• Мы мы достигли MAX_CONNECTIONS MYSQL и увеличили его со 151 до 2000.

После всего этого все, казалось, шло нормально. Хотя у нас возникла еще одна проблема, связанная с максимально разрешенным открытым TCP-соединением на порт, которое сервер использует для подключения к MYSQL и REDIS.

• Эта проблема приводила к следующая ошибка: "Невозможно назначить запрошенный адрес"

Мы запустили простой стресс-тест путем обращения к одной конечной точке, которая считывает данные как из MySQL, так и из Redis
1000 одновременных запросов, отправленных 50 раз, всего 50 тысяч последовательных запросов
При отметке в 35 тысяч запросов запросы начинали завершаться неудачно с указанной выше ошибкой. После дальнейшей проверки и запуска netstat -anlp | греп :3306 | grep TIME_WAIT -wc во время стресс-теста мы заметили, что число растет и растет по мере поступления запросов, оно быстро достигает 35 тыс., и в этот момент начинает возникать эта ошибка. Кажется, что эти соединения TIME_WAIT закрываются через 60 секунд. В ходе исследования мы попытались снизить это число до 3 секунд с помощью net.ipv4.tcp_fin_timeout = 3 и sysctl -p, но безрезультатно:/ Соединения всегда остаются открытыми в течение 60 секунд, и это вызывает большое узкое место при большой нагрузке.
Что нам делать?
PS: ОЗУ и ЦП работали нормально при простой нагрузке тест.

Подробнее здесь: https://stackoverflow.com/questions/790 ... heavy-load