Но мы не использовали постоянных подключений. Почему много неактивных соединений? Мы заметили, что с помощью команды «show processlist» время составило около 4000-8000 секунд. Эти связи выглядели как всегда «спящие». Мы используем Nginx с PHP в режиме fast-cgi и используем библиотеку PDO. Какие-либо предложения?
Похоже, что клиент не закрывает свои соединения должным образом, поэтому сервер держит их там, пока не истечет время ожидания. Если клиент просто открывает соединение, затем выполняет запрос, а затем прерывает соединение, это НЕ закрыто (даже если клиент больше не может получить к нему доступ после того, как выбросил дескриптор). Насколько я понимаю, веб-сервер должен закрыть эти соединения после завершения страницы. Похоже, этого не происходит. А почему я не знаю.
Значение тайм-аута по умолчанию на сервере составляет 6 часов, что означает, что на веб-сервере это может легко создать до нескольких тысяч соединений, ожидающих тайм-аута.
set-variable = long_query_time = 120 set-variable = wait_timeout = 28000 set-variable = connect_timeout = 25
хммм, это зависит от обстоятельств.
Конечно, СУБД сама по себе эти соединения не изобретет. Хотя накладные расходы на создание соединения с mysql невелики, все равно будет разрыв между созданием соединения и запуском запроса, а также между завершением запроса и полностью опрашиваемыми результатами, а затем еще один разрыв перед закрытием скрипта. вниз соединение. Они будут еще более выраженными, если ваш код откроет соединение до того, как оно потребуется, и / или будет слишком долго ждать, прежде чем закрыть соединение.
Однако при отсутствии постоянных соединений нет веб-программного обеспечения должен удерживать соединение открытым более пары секунд. Если у вас включена репликация mysql, это будет отображаться как поток, запущенный с момента запуска.
Что значит
SHOW FULL PROCESSLIST
(из оболочки mysql) показать?
Я заметил, что вы отметили fastcgi. Я подозреваю, что это твоя проблема.
PHP (при условии, что это то, с чем вы это делаете) завершает соединение только после выхода интерпретатора и начала очистки, то есть соединение остается открытым как простаивающее до момента сборки мусора. FastCGI обычно не завершается, поскольку он работает как служба, поэтому вы испытываете такое долгое время сна.
Лучший способ исправить это - явно объявить mysql_close () в конце вашего кода. В любом случае, лучше всего убирать за собой! Но в качестве обходного пути клуджа вы можете установить wait_timeout в mysql для разрушения соединений.