Мониторинг max_connections Mysql, чем?

[smsupport]

Очень нужен скрипт или модуль. Не важен вид. Главное мониторинг за 24 часа + простота установки (для блондинки) + сводка за неделю. Спасибо!

[chesser]

Сообщение от smsupport

Очень нужен скрипт или модуль. Не важен вид. Главное мониторинг за 24 часа + простота установки (для блондинки) + сводка за неделю. Спасибо!

max_connections

1) зачем мониторить конфиг-переменную? какую ее установишь, такая она и будет формулировка топика кривая

2) определись, что именно тебе надо мониторить. Я примерно понял, что имеется ввиду, но там несколько вариантов, например: Aborted_clients, Aborted_connects, Connections, Threads_running и тд
3) не понятно в чем отличие: "мониторинг за 24 часа" и "сводка за неделю" - это одинаковый функционал
4) из готового софта я использую munin, он по дефолту умеет мониторить 20-30 счетчиков и красиво записывать статсу в rrd и выводить ее в графики разных масштабов. Сам не поставишь, если не админ. Есть еще cacti, zabbix, nagios и прочие new relic
5) если надо топорно, то можно самому воткнуть в крон скрипт наподобие:

date +"%D %T" >> connections.log; mysqladmin -uroot -pYOURMYSQLROOTPASSWORD extended-status | grep -i "Threads_running" | cut -d'|' -f3 | tr -d ' ' >> connections.log

вместо Threads_running вписать то, что требуется мониторить. Посмотреть полный список переменных так:

mysqladmin -uroot -pYOURMYSQLROOTPASSWORD extended-status

[smsupport]

chesser, Ты прав. Мне нужно избежать ошибку "Too many connections". Мунин то, что нужно. Спасибо!

[chesser]

еще бывают т.н. "расширенные плагины" для анализа mysql. Почитай про них, там есть какой-то connections, может поможет.
(Это я про них писал, что могут быть трудности с установкой...там перл-модули надо ставить)

а чтобы избежать ошибки "Too many connections" надо:
1) оптимизировать все имеющиеся SQL-запросы, чтобы не создавалось "затора" в очереди. В 95% случаев проблема в неоптимально написанных sql-запросах (и их взаимодействии между собой), которые ухудшают производительность с ростом объемов данных. Часто таких разновидностей запросов мало, но они тормозят весь сервер, не давая другим работать, например, блокируя таблицы. Иногда эти запросы выполняют бессмысленные функции, либо их можно переписать иным образом сведя их влияние до 0.
2) если не помогло и на сервере действительно есть проблемы с пропускной способностью и много свободной оперативной памяти, то надо увеличить значение max_connections (а также open files через ulimit и прочая магия).
3) пункт 2) делать в комплексе с оптимизацией размеров буфферов: как общих для коннектов, таки и тех, которые выделяются под один коннект, для этого можно использовать калькулятор. В начале рекомендуется устранить все превышения порогов по общим буферам, а далее уже смотреть коннект-буферы. Инструменты для анализа статистики MySQL - выбрать любой и сделать так, чтобы он не "ругался" на значения статсы сервера.

Если надо срочно решить проблему, попробуй включить mysql-кеш в my.cnf:

query_cache_size=500M
query_cache_limit=1M
low-priority-updates=1

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

UPD обновил немного текст

[smsupport]

chesser, прокомментируй плз скриншот графика ОЗУ.

Мой конфиг: Centos x64, i7-2600, 16 Гб ОЗУ.

P.S. Протюнил Mysql (mysqltuner.pl - не выдает ошибок), стал выпадать апачь в пиковую нагрузку. Возможно из-за ОЗУ? На LA графике видно всплеск.

[chesser]

Сообщение от smsupport

chesser, прокомментируй плз скриншот графика ОЗУ.

Мой конфиг: Centos x64, i7-2600, 16 Гб ОЗУ.

P.S. Протюнил Mysql (mysqltuner.pl - не выдает ошибок), стал выпадать апачь в пиковую нагрузку. Возможно из-за ОЗУ? На LA графике видно всплеск.

сорри, про апач не могу ничего сказать, использовал его последний раз года 4 назад

а в момент пика, сколько коннектов у апача? тоже максимум? (должен быть такой график)
если это именно пиковые выпады апача, то да, наверно ему не хватает памяти. Точнее не так, в настройках апача стоит, что можно использовать больше памяти, чем ее в реале существует на данный момент. Можно апачевские настройки покрутить.

И поставь nginx, если до сих пор не стоит

пока ищешь причину, в мунине поставь трекинг раз в 3 минуты, например. Чтобы иметь более четкий график. А потом вернешь обратно на дефолтные много минут. Это меняется в кроне.

[lorien]

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