Разыскивание утечек Подключения mysql

У меня есть сервер приложений (причал 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 сверху).

У меня есть ТЕСТОВЫЙ ENV для этого сервера, но он никогда не имеет проблем. Это, очевидно, не получает много трафика, и сервер приложений постоянно становится перезапущенным настолько отлаживающий нет большого количества справки. Я предполагаю, что мог вырыть в каждое отдельное приложение и записать нагрузочный тест, который поразит код базы данных, но это заняло бы много времени / стычка.

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

6
задан jckdnk111 19 January 2010 в 16:04
поделиться

4 ответа

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

wait_timeout=60
interactive_timeout=60

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

Время ожидания по умолчанию Убить stare Connection - 22800 секунд Отказ Чтобы проверить:

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

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

net.ipv4.tcp_fin_timeout = 15

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

Отредактируйте 2: /etc/init.d/mysql Reload не на самом деле не перезагрузится My.cnf (см. Ссылку ниже)

3
ответ дан 17 December 2019 в 04:47
поделиться

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

Помимо того, что все, о чем я могу подумать, это то, что какой-то кусок кода удерживает набор результатов, BT, который кажется менее вероятным. Чтобы поймать, если это медленное запрос, которое время, которое вы можете также установить MySQL, чтобы написать на медленный журнал запросов в файле CONF, и он напишет все запросы, которые занимают дольше x секунд (по умолчанию 5, я думаю) Отказ

2
ответ дан 17 December 2019 в 04:47
поделиться

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

0
ответ дан 17 December 2019 в 04:47
поделиться

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

0
ответ дан 17 December 2019 в 04:47
поделиться
Другие вопросы по тегам:

Похожие вопросы: