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

Question

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

netstat -ntu | grep TIME_WAIT

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

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

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

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

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

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

Answer 1

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

wait_timeout=60
interactive_timeout=60

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

Время ожидания по умолчанию для разрыва устаревшего соединения составляет 22800 секунд. Для проверки:

mysql> show variables like 'wait_%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 60    |
+---------------+-------+

РЕДАКТИРОВАТЬ: я забыл упомянуть, я также добавил следующее в мой /etc/sysctl.conf:

net.ipv4.tcp_fin_timeout = 15

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

РЕДАКТИРОВАТЬ 2: /etc/init.d/mysql перезагрузка действительно не перезагрузит ваш my.cnf (см. Ссылку ниже)

Answer 2

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

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

Answer 3

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

Answer 4

У меня была такая же проблема с +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 5

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

Answer 6

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