Usr sbin mysqld жрет много памяти
чтобы оценить использование ОЗУ, я использую эту формулу:
эта формула производит около 5,3 ГБ расчетного распределения. Вместо этого Оперативная память, используемая MySQL, продолжает расти, и через пару дней активности она значительно превышает 9 ГБ (сильно записывается в swap).
что я упустил? Как может Я понимаю, кто ест оставшегося барана?
еще несколько кусочков информации.
Я запускаю MySQL CE 5.6.17 на RHEL6.3 64 бита. Мой сервер имеет 6 ГБ ОЗУ и 8 ГБ пространства подкачки. У меня постоянно около 150 живых подключений к MySQL, но я держу max_connections к более высоким значениям, чтобы приспособить пики и предвидеть некоторый трафик на этой машине. Я использую только InnoDB. Мое приложение использует объединенные подключения к БД. Производители открывают соединения и выпускают их в бассейн, когда они сделали. Я измерил, что у меня всегда есть несколько параллельных запросов, и объединение ускоряет создание немного соединений (так быстрее запросов). Пул (DBCP) автоматически настраивает разумное количество живых соединений, и обычно это около 100-150. Я уже пробовал:
- убийство соединений не освобождает ОЗУ
- флеш-таблицы не освобождают ОЗУ
после моего config:
это память, выделенная mysql после нескольких дней активности:
дополнительная информация на моем сервере:
как было предложено, я работал с и без секционирования на моем сервере (у меня есть 5 таблиц с 2000 разделов каждый), и кажется, что отключение секционирования помогает в некотором роде. Но все же у меня нет ясной причины, и я не могу устранить разделение вообще.
если я правильно читаю вывод, соответствующая утечка не найдена, и у меня есть огромное потребление памяти на соединение (500 МБ каждого соединения).
это правильно? Есть идеи, почему он так сильно растет?
словарь данных InnoDB может расти без границ, как вы открываете много таблиц, за innodb_additional_mem_pool_size, и он часто растет огромный, если у вас есть тысячи таблиц. Это не зависит от количества соединений.
Я видел, как другие люди сообщают, что MySQL 5.6 имеет много использования памяти, но мы не отследили его окончательно. Нужно было бы запустить mysqld под valgrind, чтобы отслеживать рост памяти.
MySQL 5.7 все еще находится под разработка, но они создают новые инструменты PERFORMANCE_SCHEMA для отслеживания использования памяти.
Если память, сообщаемая только словарем данных InnoDB, не учитывает рост памяти, я предлагаю прочитать следующие отчеты об ошибках, чтобы узнать, применяются ли они в вашем случае:
Но, с этими настройками использование памяти наоборот выросло до 20%.
Значения по умолчанию дают 18%.
Пробовал менять значения - удавалось сбить до 10%. Но, наверное и это много.
Mysqltuner.pl
innodb_buffer_pool_size = 1024M для Вашей базы слишком большой
Можно уменьшить до 256 Mb
p.s. все эти советы в статьях - это может сказаться как в лучшую так и в худшую сторону
Нет универсального решения, всё нужно тюнить под конкретные нагрузки/объёмы базы
Уменьшить буффер innodb, как вам выше написали. Уменьшить количество соединений и вообще 20% это норм.
vm.swappiness = 10 или меньше в sysctl, чтобы в swap не лезло.
Mobiaaa:
innodb_buffer_pool_size = 1024M для Вашей базы слишком большой
Можно уменьшить до 256 Mb
p.s. все эти советы в статьях - это может сказаться как в лучшую так и в худшую сторону
Нет универсального решения, всё нужно тюнить под конкретные нагрузки/объёмы базы
Спасибо за совет!
Уменьшил это значение с 1 Гб. до 134 Мб.
Использование памяти mysql снизилось с 1530 до 1300 мб.
top показывает использование памяти 12,8% (было)
Вспомнил один случай из своей жизни.
Это было больше 10 лет назад.
Я купил компьютер и не умел даже драйвер с диска для диалап модема поставить.
Но, на самом компе поставил разные проги, которые показывают температуру проца, винта, всякие показатели питания и т.д. И вдруг, одна прога показала, что возможно проц перегревается, что нет нормальной вентиляции и т.д.
Я сразу за системник и на сервис. Пришел такой полный ламер и мастера на меня смотрят и говорят: ну, рассказывай, что там случилось?
Я: проц перегревается!
А они: а ты откуда знаешь?
Я уверено: прога показала.
Честные ребята попались, успокоили меня и выпроводили по быстрому, чтобы мозги не трах**.
А современные мастера уже бы пол компа пересобрали, чтобы проц не грелся ))) (бабки рулят).
Прошу подсказать, как сделать так, чтобы не активные процессы apache2 автоматически убивались. При каждом выполнении скрипта появляется процесс apache2, который ест память и собственно который был задействован при выполнении этого скрипта.
выглядит это так
top - 02:14:21 up 45 min, 1 user, load average: 0.00, 0.12, 0.09
Tasks: 89 total, 1 running, 88 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.2%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1034452k total, 518660k used, 515792k free, 9664k buffers
Swap: 0k total, 0k used, 0k free, 96936k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2094 www-data 20 0 222m 174m 5936 S 0 17.2 1:41.25 apache2
2091 www-data 20 0 222m 174m 5936 S 0 17.2 1:20.33 apache2
1191 mysql 20 0 137m 22m 5876 S 0 2.2 0:39.67 mysqld
2090 www-data 20 0 45780 13m 5232 S 0 1.3 0:00.24 apache2
2093 www-data 20 0 45380 12m 5028 S 0 1.3 0:00.30 apache2
2101 www-data 20 0 44152 11m 5236 S 0 1.2 0:00.24 apache2
2067 root 20 0 42876 11m 6108 S 0 1.1 0:00.09 apache2
1. KeepAlive off
2. MaxRequestsPerChild 100
На firstvds это как-то автоматически убивается, на ВДС-ке другого хостера процессы упорно висят.
в той же секции, где и MaxRequestsPerChild поставьте. И будет не более 20 процессов.
По топу видно что процессы активно работают
Значит ваши скрипты чтото делают
За что же их убивать?
Проблема не в количестве процессов или вы имели в виду что-то другое.
Andreyka:
По топу видно что процессы активно работают
Значит ваши скрипты чтото делают
За что же их убивать?
Как раз не работают. На сервере запускается 1 скрипт (вручную). При каждом запуске задействован 1 процесс apache2 и некоторые другие, причём каждый раз новый. На последних секундах выполнения скрипта % используемой памяти возрастает с 4 до 17-20 и всё, в таком состоянии процесс apache2 остаётся.
При следующем запуске всё повторяется. Таким образом, в TOP появляется после 3 запусков 3 процесса apache2 (после 4-х 4-е и т.д.), каждый из которых использует 17-20 % памяти, но ни один из них не активен.
Самое интересное, что если запускать по крону тот же скрипт /usr/bin/php -q путь к скрипту, то вместо apache2 работает php и при завершении работы память высвобождается прямо во время завершения скрипта. Т.е. последняя секунда 17 % памяти использует php, следующая 0 % (процесс php килится).
PS На ВДС хостинге firstvds процесс apache так же занимает память на последних секундах и килится после выполнения скрипта. Вот я и хочу понять, т.к. скрипты запускаются аналогичные, причину такого поведения второго сервера. Думал, причина в конфике apache, но они идентичны на этих двух серверах. Значит, причина где-то ещё.
scrivente, все что вы описываете - нормальное поведение apache.
Нужно просто научиться с этим жить. Поэтому вам и советуют изменить количество процессов и количество запросов перед остановкой одного процесса.
Подбирайте эти значения до удовлетворения.
Из тех же соображений ставят nginx, если речь все-таки идет о сайте с реальными пользователями. И вы поставьте.
В некоторых хороших скриптах техника программирования такова, что они специально удаляют использованные массивы и объекты перед тем как перейти к следующему шагу обработки. Таким образом общая планка памяти ниже.
MySQL со старта жрет 1500 Мб (чистый сервер)
Вопросы по работе Сервера баз данных
MySQL, PostgreSQL, MariaDB, Percona Server, phpMyAdmin, phpPgAdmin
MySQL со старта жрет 1500 Мб (чистый сервер)
Post by pligin » Sat Mar 11, 2017 10:52 pm
Всем привет.
Не так давно на моих серверах появилась проблема с нехваткой памяти для MySQL постоянно начал падать, не запускаться т.п.
Я отключал все, что только можно. НО.
Решил, я все таки, снести один сервер под ноль.
(VPS на Digitalocean)
Поставил Debian 8 x64 и установил VestaCP. И о ужас.
На сервере ничего не работает, а MySQL уже жрет больше 1500 Мб памяти.
Что такое?
Postgresql = 7 Мб.
Может все таки пора на Postgresql съезжать?
Post by yariksat » Tue Mar 14, 2017 10:53 am
pligin wrote: Всем привет.
Поставил Debian 8 x64 и установил VestaCP. И о ужас.
На сервере ничего не работает, а MySQL уже жрет больше 1500 Мб памяти.
Что такое?
Postgresql = 7 Мб.
Может все таки пора на Postgresql съезжать?
Ага,аналогично только вчера - после старта от 2300 до 2800 и апач за 700 почти постоянно.
Не стал эксперементы ставить и накатил 7 с которой и раньше работал
Post by pligin » Tue Mar 14, 2017 11:28 am
pligin wrote: Всем привет.
Поставил Debian 8 x64 и установил VestaCP. И о ужас.
На сервере ничего не работает, а MySQL уже жрет больше 1500 Мб памяти.
Что такое?
Postgresql = 7 Мб.
Может все таки пора на Postgresql съезжать?
Ага,аналогично только вчера - после старта от 2300 до 2800 и апач за 700 почти постоянно.
Не стал эксперементы ставить и накатил 7 с которой и раньше работал
На Debian 7 была такая же проблема - я и начал эксперементировать.
На Debian 8 улучшений нет - оставил, какая разница
Post by yariksat » Tue Mar 14, 2017 3:08 pm
pligin wrote: Всем привет.
Поставил Debian 8 x64 и установил VestaCP. И о ужас.
На сервере ничего не работает, а MySQL уже жрет больше 1500 Мб памяти.
Что такое?
Postgresql = 7 Мб.
Может все таки пора на Postgresql съезжать?
Ага,аналогично только вчера - после старта от 2300 до 2800 и апач за 700 почти постоянно.
Не стал эксперементы ставить и накатил 7 с которой и раньше работал
На Debian 7 была такая же проблема - я и начал эксперементировать.
На Debian 8 улучшений нет - оставил, какая разница
Ну у меня на дебиан 7 показатели в три раза меньше.Вчера решил обновиться,обновившись посмотрел на эти показатели и откатился обратно.Желания крутить конфиги и смотреть почему оно так нет времени.
Post by skurudo » Wed Mar 15, 2017 6:28 am
Базы данных всегда жрали и будут жрать память, так уж повелось.
Исключение может sqlite ;-)
Если умеете готовить постгрю, конечно.
Post by skurudo » Mon Mar 20, 2017 2:11 pm
Post by yariksat » Sat Apr 01, 2017 10:52 am
Честно говоря я не совсем могу понять показания.
Вот
mysql Процессор: 0.9 Память: 2658 мб + apache2 Процессор: 0.2 Память: 718 мб + nginx Процессор: 0.1 Память: 181 мб и + ещё и это fail2ban Процессор: 0 Память: 798 мб память дожно было сожрать уже давно.Тем не менее.
Intel Xeon E312xx (Sandy Bridge)
Intel Xeon E312xx (Sandy Bridge)
Intel Xeon E312xx (Sandy Bridge)
Стоит Debian 8.7 (x86_64).Что показывают эти значения память?
На Дебиан 7 показатель Память на многих службах был намного скромнее.Тут же такие показатели и по факту север работает намного ровнее и шустрее чем на семёрке.Я честно говоря запутался?
Скорость генерации страниц при этом выросла более чем 2.5 раза.
Я столкнулся с проблемой когда mysql вдруг начал съедать всю доступную память в системе, хотя ему чётко заданы настройки по управлению памятью такие как innodb_buffer_pool_size.. (полный список параметров ниже)
Сразу упомяну что на сервере 32Gb оперативной памяти и как только mysql ее полностью забивает система убивает процесс mysql, память освобождается и после этого mysql_safe опять запускает mysqld и память опять постепенно заполняется, и так повторяется все время.
Я точно вижу что всю память съедает MySQL.
В момент когда это началось ни какие настройки не менялись, только добавлялись новый базы и новые пользователи.
Всего на сервере около 28 баз и в каждой около 150 таблиц.
Все эти базы с таблицами что используют InnoDB за исключением нескольких баз под Wordpress, они используют MyISAM.
Опять же сразу подчеркну что mysqltuner показывает -
Maximum possible memory usage: 16.6G (52% of installed RAM)
но mysql забирает под себя больше чем 32Gb
>my.cnf
[mysqld]
user = mysql
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
skip-external-locking
max_allowed_packet = 16M
log_slave_updates = 1
relay_log = mysql-relay-bin
relay-log-purge=1
skip-slave-start
character_set_server = utf8
character_set_client = utf8
bind-address = 0.0.0.0
log_error = /var/log/mysql/error.log
skip-name-resolve
skip-locking
max_connections = 150
open-files-limit = 10240
tmpdir = /dev/shm
query_cache_size = 128M
table_cache = 2048
tmp_table_size = 64M
max_heap_table_size = 64M
thread_stack = 192K
thread_cache_size = 60
join_buffer_size = 64M
query_cache_limit=2M
key_buffer = 50M
read_buffer_size = 2M
read_rnd_buffer_size = 2M
myisam_sort_buffer_size = 64M
thread_concurrency = 8
long_query_time = 10
log-slow-queries = /var/log/mysql/slow.log
binlog-format = ROW
log-bin = /home/backup/data/mysql-updates/
expire_logs_days = 14
max_binlog_size = 1024M
innodb_file_per_table
innodb_buffer_pool_size = 6G
innodb_additional_mem_pool_size = 20M
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_file_size = 256M
innodb_log_buffer_size = 16M
innodb_flush_log_at_trx_commit = 0
innodb_flush_method=O_DIRECT
innodb_doublewrite=0
innodb_lock_wait_timeout = 50
innodb_support_xa=0
transaction-isolation = READ-COMMITTED
-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 148M (Tables: 308)
[--] Data in InnoDB tables: 33G (Tables: 3514)
[!!] Total fragmented tables: 423
-------- Performance Metrics -------------------------------------------------
[--] Up for: 19h 54m 41s (14M q [202.695 qps], 3K conn, TX: 81B, RX: 28B)
[--] Reads / Writes: 82% / 18%
[--] Total buffers: 6.3G global + 70.2M per thread (150 max threads)
[OK] Maximum possible memory usage: 16.6G (52% of installed RAM)
[OK] Slow queries: 0% (348/14M)
[OK] Highest usage of available connections: 50% (76/150)
[OK] Key buffer size / total MyISAM indexes: 50.0M/71.9M
[OK] Key buffer hit rate: 100.0% (234M cached / 1K reads)
[OK] Query cache efficiency: 64.4% (7M cached / 11M selects)
[!!] Query cache prunes per day: 2399978
[OK] Sorts requiring temporary tables: 0% (3 temp sorts / 304K sorts)
[!!] Joins performed without indexes: 136460
[OK] Temporary tables created on disk: 10% (68K on disk / 637K total)
[OK] Thread cache hit rate: 98% (76 created / 3K connections)
[!!] Table cache hit rate: 1% (2K open / 148K opened)
[OK] Open file limit used: 0% (79/10K)
[OK] Table locks acquired immediately: 100% (468M immediate / 468M locks)
[!!] Connections aborted: 12%
[!!] InnoDB data size / buffer pool: 33.6G/6.0G
-------- Recommendations ---------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Adjust your join queries to always utilize indexes
Increase table_cache gradually to avoid file descriptor limits
Your applications are not closing MySQL connections properly
Variables to adjust:
query_cache_size (> 128M)
join_buffer_size (> 64.0M, or always use indexes with joins)
table_cache (> 2048)
innodb_buffer_pool_size (>= 33G)
===============================================
__ Key _________________________________________________________________
Buffer used 1.91M of 50.00M %Used: 3.82
Current 9.35M %Usage: 18.71
Write hit 96.73%
Read hit 100.00%
__ Questions ___________________________________________________________
Total 14.60M 202.9/s
QC Hits 7.58M 105.4/s %Total: 51.94
DMS 5.10M 70.9/s 34.95
Com_ 1.91M 26.6/s 13.09
COM_QUIT 3.99k 0.1/s 0.03
-Unknown 557 0.0/s 0.00
Slow 10 s 360 0.0/s 0.00 %DMS: 0.01 Log: ON
DMS 5.10M 70.9/s 34.95
SELECT 4.21M 58.5/s 28.82 82.46
UPDATE 390.79k 5.4/s 2.68 7.66
INSERT 281.62k 3.9/s 1.93 5.52
DELETE 222.67k 3.1/s 1.52 4.36
REPLACE 0 0/s 0.00 0.00
Com_ 1.91M 26.6/s 13.09
set_option 941.16k 13.1/s 6.45
commit 859.21k 11.9/s 5.88
rollback 62.69k 0.9/s 0.43
__ SELECT and Sort _____________________________________________________
Scan 1.00M 14.0/s %SELECT: 23.87
Range 171.60k 2.4/s 4.08
Full join 137.44k 1.9/s 3.27
Range check 1 0.0/s 0.00
Full rng join 0 0/s 0.00
Sort scan 209.76k 2.9/s
Sort range 95.98k 1.3/s
Sort mrg pass 3 0.0/s
__ Query Cache _________________________________________________________
Memory usage 87.00M of 128.00M %Used: 67.97
Block Fragmnt 7.45%
Hits 7.58M 105.4/s
Inserts 3.40M 47.3/s
Insrt:Prune 1.70:1 19.4/s
Hit:Insert 2.23:1
__ Table Locks _________________________________________________________
Waited 0 0/s %Total: 0.00
Immediate 477.60M 6.6k/s
__ Tables ______________________________________________________________
Open 2048 of 2048 %Cache: 100.00
Opened 160.71k 2.2/s
__ Connections _________________________________________________________
Max used 76 of 150 %Max: 50.67
Total 4.00k 0.1/s
__ Created Temp ________________________________________________________
Disk table 68.62k 1.0/s
Table 572.51k 8.0/s Size: 64.0M
File 22 0.0/s
__ Threads _____________________________________________________________
Running 6 of 59
Cached 17 of 60 %Hit: 98.10
Created 76 0.0/s
Slow 0 0/s
__ Aborted _____________________________________________________________
Clients 14 0.0/s
Connects 486 0.0/s
__ Bytes _______________________________________________________________
Sent 81.80G 1.1M/s
Received 28.58G 397.2k/s
__ InnoDB Buffer Pool __________________________________________________
Usage 6.00G of 6.00G %Used: 100.00
Read hit 99.99%
Pages
Free 0 %Total: 0.00
Data 383.39k 97.50 %Drty: 0.00
Misc 9830 2.50
Latched 0.00
Reads 4.36G 60.6k/s
From file 527.77k 7.3/s 0.01
Ahead Rnd 20752 0.3/s
Ahead Sql 16100 0.2/s
Writes 3.45M 47.9/s
Flushes 465.81k 6.5/s
Wait Free 0 0/s
__ InnoDB Lock _________________________________________________________
Waits 16 0.0/s
Current 0
Time acquiring
Total 2137 ms
Average 133 ms
Max 311 ms
__ InnoDB Data, Pages, Rows ____________________________________________
Data
Reads 604.30k 8.4/s
Writes 465.56k 6.5/s
fsync 252.99k 3.5/s
Pending
Reads 0
Writes 0
fsync 0
Pages
Created 3.95k 0.1/s
Read 2.51M 34.9/s
Written 465.81k 6.5/s
Rows
Deleted 136.69k 1.9/s
Inserted 270.04k 3.8/s
Read 11.13G 154.7k/s
Updated 240.46k 3.3/s
Читайте также: