Mysql memory

А, ну так у вас еще и мега пордакшон какой-то в таком состоянии..... я пока склонен к мнению [umka], возможно при переходе кое какие значения поменяли свои default values, при этом если у вас столько мощный сервер и вы понимаете зачем он вам, вы должны знать что буферы SQL расходуются на каждое соединение..... по этому вам не стоит искать 5 гиговые величины, это может быть 1Mb * 10000 соединений :D Судя по графику, тенденция идет "наполнительная", таким образом это больше всего похоже на кеш... посмотрите состояние вашего кеша в SQL , сколько там чего лежит, сколько закешировано.....

Так же напомню вам о том, что буфера резервируются ВСЕГДА, даже если они полностью не использованы т.е может получиться ситуация когда при добавлении X доп. коннектов вполне не кисло может плеснуть избыток накрутки одного из буферов. На сколько я понимаю, у вас munin, по этому покажите нам график самого SQL (query / cache / select / insert), за тот же период.

Но ведь судя по графику вы уже два раза перезапускали mysql.

Они могут и перестать быть критичными, когда вы узнаете за какие деньги Percona эти проблемы решает.

Откатите. Утечки памяти бывают во всех программах. Тем более, речь идет о программе, которая никогда не останавливается и не очищает память.

Вот даже есть недавнее изменение связанное с памятью https://bugs.launchpad.net/percona-server/+bug/1099774, но не обязательно дело в нем.

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

Графики вложил.

Судя по всему нужно будет откатывать( Попробую поменять значения буферов, посмотрим что изменится.

netwind

Нет, я не перезапускал, перкона как уперлась в лимит свободной оперативы, так сама буферы очистила.

если поможет, то могу сделать принтскрины текущих параметров настроек мускула.

это вы из чего заключили? так и написано в логах? А может mysqld_safe перезапустил mysql ?

Ну что за колхоз ? Как их потом читать ? Лучше файлы выкладывайте.

Если подозреваете изменение дефолтных значений параметров, установите предыдущую версию, запишите в файл результат запроса show global variables и сравнивайте с теми же данными на реальном сервере.

Впрочем, я бы на это не надеялся. Вы точно знаете, что незначительно изменилась версия и больше ничего не делали. Сама собой возникает мысль об обычной утечке памяти как ошибке программистов. Там в percona не только гуру работают. Если следить за историей изменений, немало странных ошибок внесенных самой же percona и исправляется.

Grohotun, а mysqltuner что скажет вообще? пробовали запускать на MYSQL который > суток Online?

Вложил текущий конф и вывод тюнера.

Интересно, как же у вас mysql доходит до 4 гб когда ограничения буферов говорят , что там не более 2 GB должно быть... парадокс... имхо течет память......

А dmesg в системе ничего не показывает ядерного типа segfault ?

смущает вот что:

1. table_open_cache (всего 400 таблиц в кеше, а пишет что всего >4k)

2. key_buffer_size ( у вас правда в myisam не более 8 метров ключей?)

Вывод mysqltuner какой-то странный, что за версия скрипта?

Version: 1.6-r1

Нет, segfault на mysql нету, есть только несколько на php-fpm, но его child респаунятся после отработки 100 запросов.

1. попробую увеличить

2. как проверить?

Мы видимо о разном, я об этом:

У меня вывод mysqltuner выглядит иначе, по этому не знаю как у вас, но я полагаю что сойдет что-то типа:

Прошелся тюнером сегодня:

>> MySQLTuner 1.2.0 - Major Hayden <major@mhtx.net>

>> Bug reports, feature requests, and downloads at http://mysqltuner.com/

>> Run with '--help' for additional options and output filtering

[OK] Logged in using credentials from debian maintenance account.

-------- General Statistics --------------------------------------------------

[--] Skipped version check for MySQLTuner script

[OK] Currently running supported MySQL version 5.5.30-30.2-log

[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------

[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster

[--] Data in MyISAM tables: 306M (Tables: 244)

[--] Data in InnoDB tables: 3G (Tables: 4214)

[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)

[--] Data in MEMORY tables: 1M (Tables: 204)

[!!] Total fragmented tables: 1608

-------- Security Recommendations -------------------------------------------

[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------

[--] Up for: 2d 2h 38m 0s (70M q [386.626 qps], 389K conn, TX: 144B, RX: 35B)

[--] Reads / Writes: 85% / 15%

[--] Total buffers: 3.3G global + 2.8M per thread (151 max threads)

[OK] Maximum possible memory usage: 3.7G (23% of installed RAM)

[OK] Slow queries: 0% (4/70M)

[OK] Highest usage of available connections: 37% (56/151)

[OK] Key buffer size / total MyISAM indexes: 8.0M/268.4M

[OK] Key buffer hit rate: 99.5% (32M cached / 159K reads)

[OK] Query cache efficiency: 81.6% (53M cached / 65M selects)

[!!] Query cache prunes per day: 4265706

[OK] Sorts requiring temporary tables: 0% (72 temp sorts / 4M sorts)

[!!] Joins performed without indexes: 62681

[OK] Temporary tables created on disk: 12% (1M on disk / 8M total)

[OK] Thread cache hit rate: 98% (6K created / 389K connections)

[!!] Table cache hit rate: 0% (400 open / 320K opened)

[OK] Open file limit used: 0% (37/65K)

[OK] Table locks acquired immediately: 99% (42M immediate / 42M locks)

[!!] InnoDB data size / buffer pool: 3.1G/3.0G

-------- Recommendations -----------------------------------------------------

General recommendations:

Run OPTIMIZE TABLE to defragment tables for better performance

Increasing the query_cache size over 128M may reduce performance

Adjust your join queries to always utilize indexes

Increase table_cache gradually to avoid file descriptor limits

Variables to adjust:

query_cache_size (> 256M) [see warning above]

join_buffer_size (> 128.0K, or always use indexes with joins)

table_cache (> 400)

innodb_buffer_pool_size (>= 3G)

Базы в основном innodb, но есть и MyISAM некоторые.

Размеры самые большие (.MYI):

62505984

36179968

101906432

281430016 total