MySql (Percona 5.5.34-rel32.0-591)
Debian Linux 6 “Squeeze” amd64
Физичерский сервак (Intel® Core™ i7-2600 Quadcore, 16Gb). Да, десктопное железо, не ECC.

База данных небольшая примерно 350Mb, InnoDB. Нагрузки смешные - до 10 параллельных соединений.

На сервере крутится не большой сайт на LiveSteet CMS - PHP 5.4.

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

При этом SHOW ENGINE INNODB STATUS эту, захваченную память, в упор не показывает.

И "не смотря на" все работает просто прекрасно - быстро, без всяких проблем. Slow Query - нет вообще.

Никакие манипуляции с параметрами в my.cnf не помогли. Перепробовали много чего.

Пробовали общаться у Percona : http://www.percona.com/forums/questions-discussions/mysql-and-percona-server/11851-mysql-never-release-memory. Безрезультатно...

Конфиг:



Бьемся с проблемой уже довольно долго... Буду очень благодарен за любые идеи.

автор1. снизить время до
long-query-time = 1
Пробовали - ничего существенного не увидели. С производительностью запросов проблем нет - это точно. У нас В CMS есть статьи с 400+ комментариями для построения которых сотни запросов выполняются - страница строится за пару секунд, тем не менее.

автор2. запустить на целый день
> mytop
возможно вы увидите нескончаемый рост соединений, или не увидите
mytop как-то немого устарел, мне кажется. Смотреть в него - смотрели : не увидали ничего криминального. Количество соединений точно не растёт, за этим следили

автор3. если рабочий вариант 10 соединений, то уменьшите до:
max_connections = 20 Вообще сразу после старта MySQL захватывает в VIRT как по книжке : 1.6Gb - 1Gb под буфер и 600Mb под сконфигурированные 200 конектов. RES начинают расти и через какое-то время начинает расти и VIRT - паралельно. Разрыв сохраняется примерно в 1Gb. Т.е. достаточно уверенно можно предположить что утечка не связана с областью памяти которая зарезервировано под коннекты. Как выделил туда MySQL 600Mb при старте - так оно и остается там.

автор2-3. Если конекции растит в числе и их статус SLEEP,
то возможно проблемы в клиенте.
ВОобшето можно попробовать отстреливать SLEEP конекции.
на которых может висеть куча зааллокированой памяти.
мм.... я не могу слёту сказать есть ли там у нас конекты в SLEEP вообще. Но проверим. Это хоть какая-то идея. Спасиб.

автор4. Что в ерор-логе перед перегрузкой?
потел ли пациент перед кончиной? на что жаловался конкретно?

Ничего! ошибок в логах нет вообще. MySQL перегружается операционкой, в системном логе при этом стандартное сообщение линукса, о том что процесс попробовал alocate память, не смог и поэтому его убиваем - как-то так. Происходит это после 7-8 дней работы, в момент когда процессом захвачена вся доступная память.

автор5. В порядке експеримента -- отключите квери-каше на один день
query-cache-type = 0 Пробовали :) не помогает.

автор6. Поставьте монитор -- возможно на каких-либо графиках
вы увидите резкий рост памяти и свяжете этот момент
с какимнибудь клиентом который грузит мултфильм в ЦМС.
наример:
www.webyog.com
newrelic.com/plugins/new-relic-inc/52 (надо иметь newrelic)
возможно есть и бесплатные алтернативы,
посмотрите monit, god...

Понимаете, рост не эпизодический. Он постоянный. можно запустить TOP, смотреть и видеть как процесс отжирает мегабайтик-другой каждые несколько минут. Интенсивность этого явления пропорциональна загрузке сайта. Но оно и понятно - кроме CMS-ки с базой и не работает никто.

автор7. вы уверены что имено мускл жрет память?Уверены :) Там трудно ошибся. ни один другой процесс на сервере (которых совсем не много) не жрет больше пары сотен Mb.

автор8.
>> wget mysqltuner.pl
>> perl mysqltuner.pl
Смотрели. :) tuning-primer.sh понравился больше, кстати. На самом деле больше чем SHOW ENGINE INNODB STATUS эти штуки не покажут. Советы выполняли. Ничего не дало :)

netwindя, кстати, вспомнил: они там сменили библиотеку memory allocation.
где-то 5.5.30 эта хрень появилась
авторPercona Server for MySQL will now be shipped with the libjemalloc library.
http://www.mysqlperformanceblog.com/2013/04/10/percona-server-for-mysql-5-5-30-30-2-now-available/
Видел уже на другом форуме подобную проблему, но теперь не могу ссылку найти.
Весьма похоже на классическую дельфипроблему : компонентов с интернета понакачали, а как они там работают не разобрались.
Это кстати похоже на правду. Мы обнаружили проблему месяца 4 назад. Сейчас не возможно сказать, к большому сожалению, была ли проблема на сервере изначально - не следили тогда. Но есть подозрение большое, что с изначальной версией (5.5.29) её всё же не было.

Ну, откатываться на ветку 5.1 - это, мне кажется, слишком консервативное решение. Да и жить ветке 5.1, похоже, осталось не долго: 8-ой год уже пошел. Это я к вопросу "централизованных обновлениях в ОС". А вот уйти с Percona 5.5 на "родной" MySQL 5.5 похоже придётся, других идей уже нет...

ScareCrowвы хоть разобрались что конкретно память жрет или нет?
Если бы разобрались, то уже скорее всего и проблему бы решили.
Как? Я пробовал даже магию с "Massif tool from Valgrind". И оно даже заработало. Но, я должен признать, что разобраться в выводе этого инструмента, и понять где там причина - задача не для моего уровня Linux-фу. Увы.
netwindНу может тогда уж сделать апгрейд ОС до debian wheezy - там уже mysql 5.5.31 - это вполне стильно и молодежно. Апгрейд OS, слишком большой геморрой, уж простите мой французский. Проще только MySQL.

Да нет. LiveStreet работает с базой довольно прямолинейно, посредством замшелой php-библиотеки DbSimple. "ORM головного мозга" я бы это называть не стал :). Аккуратно реализованный паттерн MVC там, не более. Запросы вполне прилично написаны, базовая структура БД тоже тошноты не вызывает.

Сам-то LiveStreet и на 5.0, полагаю, будет без проблем работать - это да. Вот то что там всё жестко завязано именно на MySQL - это вот печально. Был бы выбор - никогда и не за что...

Версию 5.5 выбрали из соображений актуальности и большого количества декларированных улучшений в InnoDB - и они там действительно есть. Perconа выбрали, ибо посоветовали нам, настоятельно :)

Ну , кому интересно : замена Percona на MySQL 5.5.31 из репозитория dotdeb.org ничего не дала. Проблема так и осталась. Так что Percon-у обвиняли мы зря, дело не в этом...

netwindalexei_kНу , кому интересно : замена Percona на MySQL 5.5.31 из репозитория dotdeb.org ничего не дала. Проблема так и осталась. Так что Percon-у обвиняли мы зря, дело не в этом...
ну так надо было заменять на "дефолт". dotdeb чудики еще. Мандражируют на перкону.
Да у них как раз "дефолт", насколько я понимаю. С перконы в свой репозиторий они берут только Percona toolkit.

MySQL 5.5 для Debian Squeeze в стандартных репозиториях нет. Откатываться на 5.1 не хотим, устанавливать из исходников - пока тоже не хотим. Попробовать перейти на сборку с dotdeb.org было очень просто - поэтому и сделали попытку.

netwind, ok. Предлагаете взять пакет от сюда http://dev.mysql.com/downloads/mysql/5.5.html#downloads ?

Не хотим из исходников. По крайне мере пока...

Не хочется этот низкий уровень... в бинарниках из подключенных репозиториев есть много прелести и удобства. А из исходников пересобирать это какой-то каменный век. Нет, я понимаю, что есть свои достоинства, и вообще в мире UNIX так принято, но...