Отслеживание утечек связи MySQL

Question

У меня есть сервер приложений (причал 6 в ящике Linux), в котором размещается 15 индивидуальных приложений (индивидуальная война). Каждые 3 или 4 дня я получаю предупреждение от nagios относительно количества открытых TCP-соединений. После проверки я вижу, что подавляющее большинство этих соединений связано с сервером MySQL.

netstat -ntu | grep TIME_WAIT 

Показывает 10.000+ соединения на сервере MySQL с сервера приложений (обратите внимание на состояние TIME_WAIT). Если я перезапущу причал, соединения упадут почти до нуля.

Некоторые интересные значения из шоу статуса:

mysql> show status; 
+--------------------------+-----------+ 
| Variable_name   | Value  | 
+--------------------------+-----------+ 
| Aborted_clients   | 244  | 
| Aborted_connects   | 695853860 | 
| Connections    | 697203154 | 
| Max_used_connections  | 77  | 
+--------------------------+-----------+ 

А «шоу PROCESSLIST» не показывает ничего необычного (что я бы ожидать, поскольку большинство соединений простаивают - помните, TIME_WAIT сверху).

У меня есть TEST env для этого сервера, но у него никогда не возникло проблем. Очевидно, что он не получает большого трафика, а сервер приложений постоянно перезапускается, поэтому отладка не очень помогает. Думаю, я мог бы вникнуть в каждое отдельное приложение и написать нагрузочный тест, который попадет в код базы данных, но для этого потребуется много времени/хлопот.

Любые идеи, как я мог отследить приложение, которое захватывает все эти соединения и никогда не отпускает?

Answer 1

Ответ, кажется, добавив следующие записи в my.cnf в разделе [туздЫ] :

wait_timeout=60 
interactive_timeout=60 

Я нашел его здесь (весь путь в нижней части): http://community.livejournal.com/mysql/82879.html

по умолчанию время ожидания, чтобы убить устаревшее соединение - 22800 секунд. Для проверки:

EDIT: Я забыл упомянуть, я также добавил следующее к моему /etc/sysctl.conf:

net.ipv4.tcp_fin_timeout = 15 

Это должно помочь снизить порог на ожидания ОС перед повторным использованием ресурсов соединения.

EDIT 2: /etc/init.d/mysql перезагрузка не будет действительно перезагрузить my.cnf (ссылка ниже)

Answer 2

Ну, одна вещь, которая приходит на ум (хотя я не эксперт в этом) заключается в увеличении регистрации на mySQL и поиске всех сообщений о подключении/закрытии. Если это не сработает, вы можете написать крошечный прокси, чтобы сидеть между фактическим сервером mySQL и вашим набором приложений, который выполняет дополнительную регистрацию, и вы узнаете, кто подключается/уходит.

Answer 3

Возможно, пул (ы) пула неверно сконфигурирован, чтобы удержать слишком много соединений, и они удерживают слишком много холостых процессов.

Помимо этого все, что я могу придумать, состоит в том, что часть кода держится на результирующем наборе, что кажется менее вероятным. Чтобы поймать, если это медленный запрос, который выберет время, вы также можете настроить mysql для записи в журнал медленных запросов в файле conf, а затем записать все запросы, длина которых превышает X секунд (по умолчанию это 5, я думаю) ,

Answer 4

SHOW PROCESSLIST показывает пользователя, хост и базу данных для каждого потока.Если все ваши 15 приложений не используют одну и ту же комбинацию, вы должны иметь возможность различать эту информацию.

Answer 5

У меня была такая же проблема с +30,000 TIME_WAIT на моем клиентском сервере. Фиксированный проблему путем добавления, в /etc/sysctl.conf:

net.ipv4.tcp_syncookies = 1 
net.ipv4.tcp_tw_reuse = 1 
net.ipv4.tcp_tw_recycle = 1 
net.ipv4.tcp_fin_timeout = 30 

Тогда:

/sbin/sysctl -p 

После 2-х или 3-х минут, TIME_WAIT соединения пошел от 30 000 до 7 000.

Answer 6

/Proc/SYS/net/ipv4/tcp_fin_timeout было равно 60 в RHEL7.tcp_tw_reuse и tcp_tw_recycle был изменен на 1, а производительность улучшилась.