MySQL - too many connections

еще раз всем привет

после изменения лимита ошибка перестала вылезать но теперь просто перестают работать SQL-запросы

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 7621453

Server version: 5.1.41 FreeBSD port: mysql-server-5.1.41



Type 'help;' or '\h' for help. Type '\c' to clear the buffer.



mysql> show processlist;

+---------+-------------+-----------+--------------+---------+-------+------------+------------------------------------------------------------------------------------------------------+

| Id      | User        | Host      | db           | Command | Time  | State      | Info                                                                                                 |

+---------+-------------+-----------+--------------+---------+-------+------------+------------------------------------------------------------------------------------------------------+

| 7605080 | room_db | localhost | room_new | Query   | 16120 | Locked     | INSERT INTO `cms_foto_obj`(`cat_id`, `name`, `adres`, `region_id`, `komnat`, `opis`, `pl`, `pl2`, `p | 

| 7620037 | room_db | localhost | room_new | Query   | 16120 | statistics | SELECT COUNT(*) AS `tot` FROM `cms_foto_obj` WHERE `region_id` IN (3382) AND `cat_id` IN (10) AND `s | 

| 7620039 | room_db | localhost | room_new | Query   | 16120 | Locked     | UPDATE `cms_foto_obj` SET `shown`=`shown`+1 WHERE `id`="15935145"                                    | 

| 7620042 | room_db | localhost | room_new | Query   | 16119 | Locked     | SELECT * FROM `cms_foto_obj` WHERE `id`="16413631"                                                   | 

| 7620043 | room_db | localhost | room_new | Query   | 16118 | Locked     | UPDATE LOW_PRIORITY `cms_foto_obj` SET `shown`=`shown`+1 WHERE `id`="427"                            | 

| 7620046 | room_db | localhost | room_new | Query   | 16117 | Locked     | SELECT * FROM `cms_foto_obj` WHERE `id`="20400490"

и дальше 400 селектов в состоянии слип с временем ожидания все меньше и меньше.

также обнаружил что в момент зависания одет обновление базы...сначала удалется а потом закачивается порядка 20000 записей.....

поможет конвертирование таблицы cms_foto_obj или всей базы в InnoDB

так база вроде небольшая:

Данные 180.5 МБ

Индекс 21,259.0 КБ

Эффективность 201.3 МБ

вообще из-за чего это?

Из всех Locked нужно выделить запрос который не Locked и работает с таблицей `cms_foto_obj`

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

Но для начала можно попытаться перевести эту таблицу в innodb.

вы действительно верите что один запрос из таблицы в 180 мегабайт напичканной индексами и кешированием запросов может исполняться более 5 часов на восьмиядерном ксеоне?

А что мешает? :-)

А почему бы не верить? processlist показывает, что всё именно так.

Мне интересно взглянуть на индексы, на полный запрос и чем занят сервер в это время.

простаивает сервер

1) запрос элементарный INSERT перечисления полей VALUES перечисление значений полей

2) SELECT ..... WHERE индексное_поле1=1 AND индексное_поле2>="2009-12-11" AND индексное поле3 IN(перечисление ид)

как-то так

вот индексы

вот еще нарыл

http://iusoltsev.wordpress.com/2009/07/08/mysql-state-statistics-optimizer_search_depth/

второй запрос как-раз в статистиксе висит....может это он вешает базу?

я повторюсь :

DJ_AlieN,

пока вы не показали что нашли этот запрос.

Конечно, есть и другие способы заблокировать таблицу кроме запроса - какая-нибудь педально-ручная система сложных обновлений на уровне приложения может подать lock table и зависнуть, но это скорее редкость. Надо найти тот запрос.

Индексов, кстати дохрена. Так не делают. Да еще и с мощностью = 5 - вообще никуда не годится. Обновление такой таблицы на загруженном hdd может и правда растянуться на часы. Учтите, что mysql не использует несколько процессоров для одного запроса никогда. Фактически, у вас одноядерный ксеон.

Наверное и с остальными таблицами такая же история ? Вам, скорее нужен прикладной программист, который в курсе что такое составные индексы, да и как вообще все работает в mysql. Чистые админы понасоветуют тут.

При реально массивных обновлениях можно попробовать временно отключать индексы : alter table disable/enable keys - некоторые операции поразительно ускоряются.

2-й в списке в стейте statictics

HDD под MySQL отдельный SAS 15000 кэш 32MB

общий размер баз не больше гигабайта при этом 90% нагрузки идет именно на мышеуказанную таблицу

причем раньше все крутилось на федора кор 6 больше года и такой ошибки не было :(

есть небольшое подозрение на винт