There are many blog posts already written on topics related to “MySQL server memory usage,” but nevertheless there are some who still get confused when troubleshooting issues associated with memory usage for MySQL. As a Percona support engineer, I’m seeing many issues regularly related to heavy server loads – OR OOM killer got invoked and killed MySQL server due to high Memory usage… OR with a question like: “I don’t know why mysql is taking so much memory. How do I find where exactly memory is allocated? please help!”
Checking MySQL Server Memory
There are many ways to check the memory consumption of MySQL. So, I’m just trying here to explain it by combining all the details that I know of in this post.
- Check memory related Global/Session variables.
If you are using MyISAM then you need to check for Key_buffer_size, while using InnoDB, you can check innodb_buffer_pool_size, innodb_additional_memory_pool_size, innodb_log_buffer_size, innodb_sort_buffer_size (used only for sorting data while creating index in innodb, introduced from 5.6). max_connections, query_cache_size and table_cache are also important variables to check.
We know that whenever a thread is connected to MySQL, it will need it’s own buffers when they are doing some complex operations like FTS, sorting, creating temp tables, etc. So we also need to check the size of read_buffer_size, sort_buffer_size, read_rnd_buffer_size and tmp_table_size.
There is a very good quote from So it seems we have to understand the purpose for configuring any variable… either it is Global or Session level. I would like to explain more about that here.
For the Global variables like key_buffer_size, query_cache_size etc, MySQL always allocates and initializes the specified amount of memory all at once when the server starts. But it’s not happened for those who are global default but can be set as per-session variables, i.e For read_buffer_size, sort_buffer_size, join_buffer_size, MySQL doesn’t allocate any memory for these buffers until query needs. But when a query needs, it immediately allocates the entire chunk of memory specified. So if there are even small sorts, the full buffer size will be allocated which is just a waste of memory. Even some buffers can be used multiple times. For example, on queries that join several tables, join_buffer can be allocated once per joined table. Also, some complicated queries including sub-queries can use multiple sort_buffers at the same time which can lead to high memory consumption. In some scenario, the query didn’t even use sort_buffer whatever size is, as it selects by the primary key which will not allocate it. So it depends on the nature of your environment but I would say it’s always better to start with a safe variable value that can be larger than default if needed but not as large as it can consume all of the server’s memory.
One more thing, not all per-thread memory allocation is configured by variables. Some of the memory allocation per thread is done by MySQL itself for running complex processes/queries like “stored procedures” and it can take an unlimited amount of memory while running. And sometimes, optimizer can also take a lot of memory working with highly complex queries which generally we can’t control by any configuration parameter.
Even innodb_buffer_pool_size is not a hard limit, usually, innodb uses 10% more memory than the one specified. Many people do not recommend using both storage engine MyISAM and InnoDB at the same time on the production server. Because both have individual buffers which can eat all server memory.
For detailed information related to this topic, I would suggest reading this post from Peter Zaitsev titled “MySQL Server Memory Usage.”
- Check “SHOW ENGINE INNODB STATUS” for section “BUFFER POOL AND MEMORY“
|
1 2 3 4 5 6 7 8 9 10 |
---------------------- BUFFER POOL AND MEMORY ---------------------- Total memory allocated 137363456; in additional pool allocated 0 Dictionary memory allocated 76056 Buffer pool size 8191 Free buffers 7804 Database pages 387 Old database pages 0 Modified db pages 0 |
Above one is from Native MySQL but if you’ll check the same with Percona Server you’ll get some more information.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
---------------------- BUFFER POOL AND MEMORY ---------------------- Total memory allocated 137756672; in additional pool allocated 0 Total memory allocated by read views 88 Internal hash tables (constant factor + variable factor) Adaptive hash index 2217584 (2213368 + 4216) Page hash 139112 (buffer pool 0 only) Dictionary cache 597885 (554768 + 43117) File system 83536 (82672 + 864) Lock system 333248 (332872 + 376) Recovery system 0 (0 + 0) Dictionary memory allocated 43117 Buffer pool size 8191 Buffer pool size, bytes 134201344 Free buffers 7760 Database pages 431 Old database pages 0 Modified db pages 0 |
This will give you information regarding how much memory is allocated by InnoDB. You can see here “Total Memory Allocated”, “Internal Hash Tables”, “Dictionary Memory Allocated”, “Buffer Pool Size” etc.
- Profiling MySQL Memory usage with Valgrind Massif
Recently, I used this tool and surprisingly I got very good statistics about memory usage. Here the only problem is you have to shut down the mysql, start it with valgrind massif and after collecting statistics, you again have to shut down and normal start.
|
1 2 3 |
$ /etc/init.d/mysql stop $ valgrind --tool=massif --massif-out-file=/tmp/massif.out /usr/sbin/mysqld $ /etc/init.d/mysql restart |
After getting the massif.out file, you have to read it with ms_print command. You will see a pretty nice graph and then statistics. i.e
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 |
[root@percona1 ~]# ms_print /tmp/massif.out -------------------------------------------------------------------------------- Command: /usr/sbin/mysqld Massif arguments: --massif-out-file=/tmp/massif.out ms_print arguments: /tmp/massif.out -------------------------------------------------------------------------------- MB 50.22^ ## | # | # | # | # | # | : # | :: # ::::::@:::::::::::::@:::@::::@:::@:::: | : @::# :::::@@::::::::::::::::::: @::: ::: :::::@:::@::: @:::@:::: | : @::# : ::@ :::::::::: :: ::::: @::: ::: :::::@:::@::: @:::@:::: | : @::# : ::@ :::::::::: :: ::::: @::: ::: :::::@:::@::: @:::@:::: | : @::# : ::@ :::::::::: :: ::::: @::: ::: :::::@:::@::: @:::@:::: | : @::# : ::@ :::::::::: :: ::::: @::: ::: :::::@:::@::: @:::@::::@ | : @::# : ::@ :::::::::: :: ::::: @::: ::: :::::@:::@::: @:::@::::@ | :: @::# : ::@ :::::::::: :: ::::: @::: ::: :::::@:::@::: @:::@::::@ | ::: @::# : ::@ :::::::::: :: ::::: @::: ::: :::::@:::@::: @:::@::::@ | :::: @::# : ::@ :::::::::: :: ::::: @::: ::: :::::@:::@::: @:::@::::@: | :::: @::# : ::@ :::::::::: :: ::::: @::: ::: :::::@:::@::: @:::@::::@: | :::: @::# : ::@ :::::::::: :: ::::: @::: ::: :::::@:::@::: @:::@::::@: | :::: @::# : ::@ :::::::::: :: ::::: @::: ::: :::::@:::@::: @:::@::::@: 0 +----------------------------------------------------------------------->Mi 0 575.9 Number of snapshots: 96 Detailed snapshots: [1, 7, 11 (peak), 16, 35, 48, 58, 68, 78, 88] -------------------------------------------------------------------------------- n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B) -------------------------------------------------------------------------------- 0 0 0 0 0 0 1 6,090,089 195,648 194,590 1,058 0 99.46% (194,590B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc. ->48.79% (95,458B) 0x7A1D20: my_malloc (my_malloc.c:38) | ->25.08% (49,060B) 0x6594F1: read_texts(char const*, char const*, char const***, unsigned int) (derror.cc:160) | | ->25.08% (49,060B) 0x6597C2: init_errmessage() (derror.cc:69) | | ->25.08% (49,060B) 0x506232: init_common_variables() (mysqld.cc:3414) | | ->25.08% (49,060B) 0x508CBB: mysqld_main(int, char**) (mysqld.cc:4461) | | ->25.08% (49,060B) 0x5B2CD1B: (below main) (in /lib64/libc-2.12.so) | | | ->09.36% (18,317B) 0x789571: my_read_charset_file (charset.c:364) | | ->09.36% (18,317B) 0x789DEC: init_available_charsets (charset.c:458) | | ->09.36% (18,317B) 0x4E35D31: pthread_once (in /lib64/libpthread-2.12.so) | | ->09.36% (18,317B) 0x789C80: get_charset_by_csname (charset.c:644) | | ->09.36% (18,317B) 0x5062E9: init_common_variables() (mysqld.cc:3439) | | ->09.36% (18,317B) 0x508CBB: mysqld_main(int, char**) (mysqld.cc:4461) | | ->09.36% (18,317B) 0x5B2CD1B: (below main) (in /lib64/libc-2.12.so) | | | ->08.37% (16,384B) 0x79DEEF: my_set_max_open_files (my_file.c:105) | | ->08.37% (16,384B) 0x506169: init_common_variables() (mysqld.cc:3373) | | ->08.37% (16,384B) 0x508CBB: mysqld_main(int, char**) (mysqld.cc:4461) | | ->08.37% (16,384B) 0x5B2CD1B: (below main) (in /lib64/libc-2.12.so) | | | ->04.36% (8,536B) 0x788DB4: init_dynamic_array2 (array.c:70) | | ->02.45% (4,800B) 0x5CD51A: add_status_vars(st_mysql_show_var*) (sql_show.cc:2062) | | | ->02.45% (4,800B) 0x505E68: init_common_variables() (mysqld.cc:3245) | | | ->02.45% (4,800B) 0x508CBB: mysqld_main(int, char**) (mysqld.cc:4461) | | | ->02.45% (4,800B) 0x5B2CD1B: (below main) (in /lib64/libc-2.12.so) | | | |
You can see from the output that where memory is allocated, to which function, etc. You can use this tool to find memory leaks. You can get more information here on how to install and use it. Here’s another related post by Roel Van de Paar titled: “Profiling MySQL Memory Usage With Valgrind Massif.”
If possible Valgrind massif should not be used on busy production server as it can degrade the performance. Generally it’s used to find memory leak by creating mirror environment on test/stage server and run on it. It needs debug binary to run so it decreases performance a lot. So it can be used for investigating some cases but not for regular use.
- Check Plot memory usage by monitoring ps output.
This also useful when you want to check how much virtual(VSZ) and real memory (RSS) is used by mysqld. You can either simply run some bash script for monitoring it like
|
1 2 3 4 5 6 |
while true do date >> ps.log ps aux | grep mysqld >> ps.log sleep 60 done |
Or you can also check when needed from shell prompt with “ps aux | grep mysqld” command.
- Memory tables in MySQL 5.7
With MySQL 5.7, some very interesting memory statistics tables are introduced to check memory usage in performance_schema. There is no any detailed documentation available yet but you can check some details here. http://dev.mysql.com/doc/refman/5.7/en/memory-summary-tables.html
In P_S, there are five memory summary tables.
|
1 2 3 4 5 6 7 8 9 10 11 |
mysql> show tables like '%memory%'; +-----------------------------------------+ | Tables_in_performance_schema (%memory%) | +-----------------------------------------+ | memory_summary_by_account_by_event_name | | memory_summary_by_host_by_event_name | | memory_summary_by_thread_by_event_name | | memory_summary_by_user_by_event_name | | memory_summary_global_by_event_name | +-----------------------------------------+ 5 rows in set (0.00 sec) |
So with every event, you can get summarized memory consumption for a particular account, host, thread, and user. While checking more, I found that there are around 209 different events to check. I have just tried to check one event related to join buffer size.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
mysql> select * from memory_summary_by_account_by_event_name where SUM_NUMBER_OF_BYTES_ALLOC <> 0 and user = 'msandbox' and event_name = 'memory/sql/JOIN_CACHE' G *************************** 1. row *************************** USER: msandbox HOST: localhost EVENT_NAME: memory/sql/JOIN_CACHE COUNT_ALLOC: 2 COUNT_FREE: 2 SUM_NUMBER_OF_BYTES_ALLOC: 524288 SUM_NUMBER_OF_BYTES_FREE: 524288 LOW_COUNT_USED: 0 CURRENT_COUNT_USED: 0 HIGH_COUNT_USED: 1 LOW_NUMBER_OF_BYTES_USED: 0 CURRENT_NUMBER_OF_BYTES_USED: 0 HIGH_NUMBER_OF_BYTES_USED: 262144 1 row in set (0.00 sec) mysql> show global variables like 'join%'; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | join_buffer_size | 262144 | +------------------+--------+ 1 row in set (0.00 sec) mysql> |
Here, COUNT_ALLOC, COUNT_FREE are aggregate the number of calls to malloc-like and free-like functions. SUM_NUMBER_OF_BYTES_ALLOC and SUM_NUMBER_OF_BYTES_FREE are indicating the aggregate size of allocated and freed memory blocks. CURRENT_COUNT_USED is the aggregate number of currently allocated blocks that have not been freed yet. CURRENT_NUMBER_OF_BYTES_USED is the aggregate size of currently allocated memory blocks that have not been freed yet. LOW_ and HIGH_ are low and high water marks corresponding to the columns.
- Memory sections in output of pt-summary and pt-mysql-summary
If you are aware of these scripts then, these are giving a very good summary about overall server memory consumption as well as related to MySQL.
Like in output of pt-summary,
|
1 2 3 4 5 6 7 8 |
# Memory ##################################################### Total | 11.8G Free | 143.7M Used | physical = 11.6G, swap allocated = 4.0G, swap used = 0.0, virtual = 11.6G Buffers | 224.9M Caches | 6.2G Dirty | 164 kB UsedRSS | 4.8G |
In output of pt-mysql-summary.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# Query cache ################################################ query_cache_type | OFF Size | 0.0 Usage | 0% HitToInsertRatio | 0% # InnoDB ##################################################### Version | 5.5.30-rel30.2 Buffer Pool Size | 4.0G Buffer Pool Fill | 35% Buffer Pool Dirty | 1% # MyISAM ##################################################### Key Cache | 32.0M Pct Used | 20% Unflushed | 0% |
Conclusion:
It is really important for us to know where MySQL allocates memory and how it affects the overall load on the MySQL server and performance. I have just tried here to describe a few ways but I still think that we should have some sort of script or something that can combine all of these results and gives us some truthful output of memory usage in MySQL.
More resources:
Posts
- Best practices for configuring optimal MySQL memory usage
- MySQL 5.7 performance tuning immediately after installation
- Ten MySQL performance tuning settings after installation
Webinars
- Top most overlooked MySQL performance optimizations
- Percona Server for MySQL 5.7: key performance algorithms
Presentations
Free eBooks
- Practical MySQL Performance Tuning: section 1 – understanding query parameter tuning and MySQL optimization
- Practical MySQL Performance Tuning: section 2 – troubleshooting performance issues and optimizing MySQL
- Practical MySQL Performance Tuning: section 3 – query optimization
Comments (15)
Nice article to capture the memory usage.
I love using Valgrind Massif for memory stats and also the pt-summary as well.
how many of the status for memory consumption that the percona server displayed above are configurable (ofcourse excluding the usual buffers and the caches we already can change)?
While its good to know how much memory is being used behind the scenes, it would really help if we can configure/control it.
Hi Shamim,
Thanks. Can you please elaborate your question? Are you asking for P_S (Performance Schema) related memory usage or something else? If it’s P_S related which introduced from 5.6 then you can check with
SHOW GLOBAL VARIABLES LIKE “performance_schema%”;
Check more details in comments here about memory consumption and related variables for P_S.
http://bugs.mysql.com/bug.php?id=68514
http://bugs.mysql.com/bug.php?id=69490
But still proper documentation is needed for the use of P_S in MySQL 5.6.
Are you for hire? We would like someone with your skills to look at our Linux OpenSUSE system that is running Server version: 10.1.20-MariaDB openSUSE.
It is an running software called Vicidial which uses Asterisk and Apache.
Heaving disk activity, lots of simple inserts and updates taking place rapidly.
We have it on Samsung SSD drives in a RAID 1.
We have many servers without a RAID that run very well.
The database in total is 25G, there about 5 tables all containing approximately 10 million records.
One might suggest archiving but it was working fine before we upgraded the server.
Very strange. There are 2 differences from other systems that work fine.
1) RAID 1
2) New Version of Vicidial Software (but there are not complaints on the forums for this upgrade).
really need to be sure the my.cnf file is optimized.
NOTE: We never see the CPU’s fully loaded, never see memory getting utilized.
System has: Dual Zeon Hexcores with 32G of ram.
Lost as to how it could be getting sluggish and have no sign of stress.
Let me know if you or someone can take a look for an agreed fee.
Thank you,
Greg
Greg I’ve just sent you an email with contact information.
Thank you,
Nikki
Very good. Thank you.
Please check this one to substantiate this further : http://blog.triantech.com/memory-drain-issues-on-mysql-5-6/
Hi Nilandan,
I m begineer for sql database, please help me or guide me to learn and practice of sql database. i lm working in Datacenter for technical support issues.
Regards,
Pavan
I have website tradedeal.in.I have 50 lakh data but my sql show 70% memory use
please check screen shot http://tradedeal.in/Untitled.png
Nice article post ,Thank you 🙂
Hi Nilnandan ,
I have issue of MySQL Memory consumption.
There is neither CPU load nor long queries but still memory consumption is 85 % .
My.cnf:
[mysqld]
# * Basic Settings
skip-external-locking
innodb_buffer_pool_size=15G
innodb_log_buffer_size=30M
innodb_file_per_table=1
skip_name_resolve
max_connect_errors=10000
max_connections=5000
#collation_connection=latin1_swedish_ci
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 0.0.0.0
# Fine Tuning
key_buffer = 32M
max_allowed_packet = 100M
thread_stack = 192K
thread_cache_size = 8
#table_cache = 64
#thread_concurrency = 10
# Query Cache Configuration
query_cache_limit = 1M
query_cache_size = 16M
log_error = /var/log/mysql/error.log
# Here you can see queries with especially long duration
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 10
#log-queries-not-using-indexes
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
# other settings you may need to change.
#server-id = 1
#log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
[isamchk]
key_buffer = 32M
How can I resolved it.
Thanks in advance.
Hello, small correction on one of the the variables names
The innodb_additional_memory_pool_size seems to actually be called innodb_additional_mem_pool_size (maybe this changed since 2014)
Hi Nilnandan,
I have one question, I have master DB with 128 GB RAM and 6 TB Flash Drive. Everything working fine but suddenly most of connections runs under “freeing item”, even simplest query also run under “freeing item.”. Sometime i get FAILED Connection also, and connected thread gradually after 2500 , application get getting connection timeout . Please help me in this issue, where i can search or digg for this issue.
mysql uses memory per thread, mysqltuner.pl says my config is using 100m/thread. So 2500 threads you might be exhausting your RAM. Perhaps I have poor tuning.
Very nice article..
We are facing some strange issue where in our mysql server is not starting and server status always remains starting but it not getting up.
we are facing this as there was less memory on the machine, but when we increased the memory of the machine and started the service it is not getting started.
any suggestions on this would be very much helpful.
Thanks in advance.
please check the configuration of your my.ini file and also and ibdata & iblog files..