Gianni Messina

Depending on what’s causing the memory bottleneck, the solution can vary.

Here are the top resolutions for MySQL high memory usage.

1. MySQL settings optimization

MySQL uses memory in two ways:

Memory permanently reserved for its use
– This category of memory known as “Global Buffers” is obtained from the operating system during server boot-up and is not released to any other process.

Memory which is requested dynamically based on requests
– MySQL uses “Thread Buffers“, which is memory requested from the operating system as and when a new query is processed. Once the query is executed, this memory is released back to the operating system.

So, you can say the memory usage of MySQL is

“Global Buffers + (Thread Buffers x maximum number of allowed connections)”.

This value should always be kept below 90% of server memory for a dedicated database server.

If it is a shared server, it should be kept below 50%.

Here are a few of the common MySQL settings that determines memory usage, and how you can decide it’s size.

innodb_buffer_pool_size
– For InnoDB storage engine, caching is done in the buffer pool. The size of the buffer pool is important for system performance and is assigned a value that is between 50-70% of available RAM. Too small pool size can cause excessive flushing of pages and too large size can cause swapping due to competition for memory.

key_buffer_size
– For MyISAM storage engine, this parameter determines the caching and key_buffer_size has to be set according to the RAM, which is around 20% of RAM size.

max_connections
– To limit the number of connections possible for MySQL at any instant of time, to avoid a single user from overloading the server, max_connections is used.
Each thread uses a portion of the RAM for allotting its buffers and hence limiting the maximum no of connections based on the RAM size is important.

Approx formula, max_connections = (Available RAM – Global Buffers) / Thread Buffers

query_cache_size
– The query cache can be useful in an environment where you have tables that do not change very often and for which the web server receives many identical queries such as a blog or record lookup.
The query cache stores the text of a SELECT statement together with the corresponding result that was sent to the client. So this parameter is used only for such application servers or otherwise disabled and set to 0 for other servers. To avoid resource contention, even if it is enabled, the value is set a minimal one of around 10MB.