Оптимизация MySQL или почему работа сервера ухудшилась

[sergibondarenko]

Добрый день

Подскажите пожалуйста по оптимизации MySQL сервера. Или посоветуйте в какую сторону лучше смотреть. Может у кого были подобные проблемы.

За последние две недели MySQL сервер падал 2 раза. Начался поиск путей оптимизации MySQL сервера.
Есть отдельный MySQL сервер (Debian), в нем хранится информация для колл-центра построенном на основе Astersik (отдельный сервер). В MySQL хранится для последующей обработки почти вся информация колл центра: очереди, агенты очередей, разные значения для IVR и dialplan, CDR и многое другое. Asterisk постоянно взаимодействует с MySQL: запрашивате кто из агентов свободен и записывает занятость агентов, записывает состояние очередей и записывает CDR и тд.
Нормальное количество звонков для системы около 100 одновременно.
В последнее время начали наблюдатся тормоза с распределением абонентов в очередях на свободных агентов колл-центра, задержка от 10 сек и до 2 мин. Подозрения на InnoDB локи и зависшие транзакции. А тут еще и сервер MySQL начал валится.

В SHOW ENGINE INNODB STATUS\G вижу много локов и транзакции что висят больше 40 сек но не могу понять как с ними боротся. И нужно ли?
2721452-*** (2) TRANSACTION:
2721453:TRANSACTION 0 1345044118, ACTIVE 45 sec, process no 23678, OS thread id 140176187664128 starting index read, thread declared inside InnoDB 0
2721454-mysql tables in use 1, locked 1
2721455-10 lock struct(s), heap size 3024, 7 row lock(s), undo log entries 2
Также в выводе есть куча другой инфы но не знаю какие можно выводы сделать по тем значениям. Подскажите пожалуйста какие параметры найболее подозрительны на вашу точку зрения.
Полный вывод за пол месяца можно найти в файле *show_engine_innodbAndProc_stat_10Apr2013

Пиковая нагрузка на CPU демоном mysqld достаточно высока как видно из графиков сделаных по данным top (нарисовано с помощью gnuplot). Но память и диски не сильно загружены. Дисковая система тоже не сильно загружена. Смотрите все графики top и iostat в *graphs
Список таблиц и их движков можно увидеть в прикрепленном файле *mysql_engines
Переменные MySQL выведены в файле *mysqlGvars.txt
Все аппаратные параметры MySQL сервера отображены в файле *phys_mysql_server

*Все файлики можно скачать по ссылке http://rapidshare.com/files/3386491301/alldata.zip

[Olej]

За последние две недели MySQL сервер падал 2 раза. Начался поиск путей оптимизации MySQL сервера.
Есть отдельный MySQL сервер (Debian), в нем хранится информация для колл-центра построенном на основе Astersik (отдельный сервер). В MySQL хранится для последующей обработки почти вся информация колл центра: очереди, агенты очередей, разные значения для IVR и dialplan, CDR и многое другое. Asterisk постоянно взаимодействует с MySQL: запрашивате кто из агентов свободен и записывает занятость агентов, записывает состояние очередей и записывает CDR и тд.
Нормальное количество звонков для системы около 100 одновременно.
В последнее время начали наблюдатся тормоза с распределением абонентов в очередях на свободных агентов колл-центра, задержка от 10 сек и до 2 мин. Подозрения на InnoDB локи и зависшие транзакции. А тут еще и сервер MySQL начал валится.

Я организовывал PBX и на Asterisk и, ещё больше, на FreeSWITCH (у FreeSWITCH производительность выше ... да и конфигурирование и диалпланы в XML - более гибкое решение). Но ни там ни там не использовал связку с MySQL для регистрации.

Не могут ли быть связаны ваши эффекты с разнесённостью MySQL (какие-нибудь ограничения на число одновременно открываемых сетевых сокетов)? И вообще не очень понятно зачем MySQL уносить на другой сервер ... порядка 100 конектов - это совсем небольшая нагрузка для PBX (на Asterisk).

В любом случае, попробуйте потестировать MySQL локально (на петлевом интерфейсе 127.0.0.1) - не пропадут ли наблюдаемые вами эффекты?
Довольно странная картина...