У нас есть веб-приложение, использующее apache и mysql. Обычно (по словам Мунина) количество потоков MySQL всегда находится между 2 и 4. На днях наш сервер почти остановился. HTTP-запросы были медленными или вообще не проходили, SSH работал бы, но регистрирование нажатий клавиш и т. Д. Занимало 30+ секунд. Итак, мы вызываем Munin, и единственное, что выходит за обычные границы, - это количество потоков Mysql. Загрузка ЦП была ниже 1%, загрузка была ниже 1.0, доступной оперативной памяти много.
Как упоминалось ранее, количество потоков колеблется от 2 до 4. Во время наших замедлений оно выросло до 14. Я начал копаться в Интернете и вижу, что в большинстве случаев вы начнете видеть поток более высокого уровня. считать, когда вы начинаете работать с медленными запросами. Если я правильно понимаю, поступает запрос, который требует времени для обработки, в то время как поступают другие запросы, поэтому будет создан новый поток для работы с запросом (да?). Но в момент замедления у нас было 0 медленных запросов.
Мой вопрос: что еще может заставить mysql создавать дополнительные потоки. И может ли этот внезапный всплеск потоков вызвать замедление работы сервера? Чтобы решить эту проблему, мы перезапустили apache, и все вернулось к своему красивому, нормальному состоянию. Учитывая, что основные параметры сервера (ЦП, ОЗУ, сеть и т. Д.) Были идеальными, а количество потоков было единственным неуместным, это кажется наиболее логичным решением в качестве возможной причины.
Если это важно, мы на Mysql 5.1.40. Сервер - FreeBSD 7.2, и рассматриваемый сервер находится внутри тюрьмы.
В зависимости от того, что делает Apache, это может вызвать множество одновременных запросов к Apache. Например, большая корявая CMS может открывать соединение MySQL на ранней стадии, долго генерировать страницу и не закрывать соединение до его завершения.
FWIW, я обнаружил, что периодический опрос текущих соединений обычно не показывает реальную картину. Ты должен посмотреть на max_used_connections. К сожалению, этой величиной сложно управлять: https://dba.stackexchange.com/questions/6040/how-can-i-get-the-maxium-number-of-concurrent-connections-to-mysql-over-a-specif
Когда это произойдет, посмотрите на вывод SHOW FULL PROCESSLIST; Посмотрите, много ли процессов в состоянии сна. Есть хотя бы один ошибка, из-за которой MySQL зависает на SHOW VARIABLES.
Вместо того, чтобы использовать:
mysql -e "show global status"|grep -i threads_connected
или lsof
вы можете рассмотреть возможность использования procfs сам с обычными утилитами GNU / Linux:
find /proc/`pidof mysqld`/fd/ -follow -type s | wc -l
Я опаздываю на вечеринку, но недавно решил аналогичную проблему. Если вы используете механизм хранения MyISAM и выполняете операцию записи, все остальные запросы чтения должны ждать, пока не будет снята блокировка на уровне таблицы. Если запрос охватывает несколько таблиц, возникают две сложности: 1. Объединенные результаты не помещаются в память, и вызывается сортировка файлов, что означает больше операций ввода-вывода на диск. и 2. больше таблиц заблокировано, поэтому запросы чтения с большей вероятностью будут помещены в очередь. В большинстве случаев MySQL завершает запись и чтение очищается. Если ОС не может снять блокировку файла (это происходит чаще, чем вы ожидали), поток MySQL зависает.