MySQL server memory usage troubleshooting tips

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“

Above one is from Native MySQL but if you’ll check the same with Percona Server you’ll get some more information.

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.

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

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

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.

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.

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,

In output of pt-mysql-summary.

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

• Practical MySQL Performance Optimization

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

Tools

• Percona Monitoring and Management