Ubuntu 22.04, БУС 23.3 (все последние обновления), 4 ядра и 32 RAM.
Днём через show proccesslist не более 10 открытых соединений одновременно. DBpersistent = false;. Последнее время после 12 ночи до 4-5 утра получаю на почту сообщения, что MySQL Too many connections и сокет недоступен. max_connections увеличил для теста с 50 до 74, но как и ранее черезshow status like '%_conn%'; вижу, что было подключений более максимум на 1-2 шт. Попробовал для теста увеличить в настройках подключения битрикса session wait_timeout = 28800. Результатов не дало.
По access логам вижу, что боты поисковиков начинают всё парсить и т.п. Спаммеров залётных забанил, но нагрузка не падает. Подскажите, пожалуйста, как оптимально можно отловить что конкретно создаёт подключения? Бездумно поднимать макс.подключения не собираюсь, нужно разобраться что происходит. Логировать Slow Query и по ним уже разбирать это ошибка разработки или в чём конкретно дело? Ранее ошибки такой не наблюдалось, месяца 2+- как появилось только
Начнём с очевидного - MySQL в интернет напрямую не смотрит?
Если смотрит - закрой.
Если не смотрит - идём дальше.
Твоё приложение открывает новое соединение на каждый запрос?
Если открывает - вводи пул соединений и ограничь его каким-нибудь разумным числом.
Если не открывает - значит нужно больше информации.
Попробовал для теста увеличить в настройках подключения битрикса
В интернет не смотрит, ограничение по количеству соединений есть, но его мало. Немного затрудняюсь ответить на вопрос про новое соединение на каждый запрос. По идее, кеш часть запросов убирает. Судя по количеству посетителей и процессов MySQL => 1 подключение != новый запрос. Пошёл изучать информацию по соединения
Для начала - выясните, что же вообще с MySQL-ем происходит. Напишите простенький скрипт, который будет в цикле, держа (и восстанавливая) одно SQL-соединение, исполнять SHOW PROCESSLIST; и дозаписывать результат в какой-нибудь лог, если кол-во коннектов больше 75% от макс. Тогда и SLOW QUERY увидите, и флуд коннектами. А дальше уже думать...
