InnoDB Buffer Pool Tuning in Enscale
If you only ever tune one thing in MariaDB, make it the InnoDB buffer pool. It's the pool of memory InnoDB uses to cache table and index data, and it's the difference between a query reading from RAM in microseconds and reading from disk in milliseconds.
Get it right and most of your working data lives in memory. Get it wrong, or leave it alone while your data grows, and you slide into disk-bound performance without ever changing a line of SQL.
Here's how to size it, how to tell whether yours is actually big enough, and why it's one of the first settings to drift as a workload evolves.
Key Takeaways
The InnoDB buffer pool decides whether reads come from RAM or disk, so it is the highest-impact setting to get right.
Size it to 50-75% of the node's memory (up to about 80% on a dedicated 8 GB or larger node), always leaving 1-2 GB for the OS, and never so large that it swaps.
Check your cache hit rate:
Innodb_buffer_pool_readsshould stay a tiny fraction ofInnodb_buffer_pool_read_requests.In Enscale the right size moves every time you resize the node, which is a common reason the pool drifts out of alignment.
What the buffer pool does
Every time InnoDB needs a row, it first looks in the buffer pool. If the data's there (a cache hit), the read is effectively free. If it isn't (a cache miss), InnoDB has to fetch it from disk, which is orders of magnitude slower. The whole game is keeping your working set, the data your queries actually touch day to day, resident in the pool so reads stay in memory.
When the pool is too small for the working set, InnoDB is forced to evict pages it will need again shortly, then fetch them back from disk moments later. That churn is where disk I/O quietly becomes your bottleneck.
How big should it be?
The common rule of thumb is to give the InnoDB buffer pool somewhere between 50% and 75% of the memory available to the database, and on a node that does nothing but run MariaDB you can push toward 80% once it has 8 GB or more to work with. The hard constraint sits at the other end: always leave enough headroom (1 to 2 GB is a sensible floor) for the operating system and everything else on the node.
The mistake to avoid is going too big. If the buffer pool plus everything else exceeds physical memory, the node starts swapping, and swapping to disk undoes the entire benefit of a large in-memory cache. A buffer pool that's too big is worse than one that's slightly too small.
In Enscale specifically, there's a wrinkle worth calling out. Memory on your database node is whatever you've allocated to it, and it can change when you scale. So "50 to 75% of RAM" means 50 to 75% of the memory reserved for that node, and every time you resize the node, the right buffer pool size moves with it. That's a big reason the setting drifts: people scale the node's resources and never revisit the pool, so it ends up sized for a machine that no longer exists.
Setting it
The variable is innodb_buffer_pool_size](https://mariadb.com/docs/server/server-usage/storage-engines/innodb/innodb-system-variables). You can change it live, without a restart:
SET GLOBAL innodb_buffer_pool_size = 6442450944; -- 6 GB, in bytesInnoDB resizes the pool online in the background, which is handy, but a SET GLOBAL value is lost on restart. To make it permanent, set it in your MariaDB configuration:
[mariadb]
innodb_buffer_pool_size = 6GIf you've read older tuning guides, you may have seen innodb_buffer_pool_instances, which used to split the pool into several independent instances to reduce contention. Modern MariaDB no longer works that way: the variable was deprecated in 10.5 and removed in 10.6, and the buffer pool is now managed as a single instance regardless of size. There's no instance count to tune anymore, so getting the size right is what matters.
How to tell if yours is too small
Don't guess, measure. The clearest signal is your cache hit rate, which you can derive from two status counters:
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';Innodb_buffer_pool_read_requestsis the number of reads served from the pool (memory).Innodb_buffer_pool_readsis the number that missed and had to go to disk.
A healthy pool serves the vast majority of reads from memory, so the second number should be a tiny fraction of the first. When Innodb_buffer_pool_reads starts climbing as a share of read requests, your working set no longer fits, and it's time to either grow the pool or investigate what's bloated your working set.
Two more quick checks. SHOW ENGINE INNODB STATUS reports a buffer pool hit rate directly in its output. And Innodb_buffer_pool_wait_free counts how often a query had to wait because InnoDB couldn't find a free page fast enough; on a healthy pool it stays at or very near zero, so if it starts climbing under normal load the pool is genuinely short of memory. Don't read too much into Innodb_buffer_pool_pages_free on its own, though: once the pool warms up it naturally sits near zero whether or not it's big enough.
Why the buffer pool drifts
You size the pool correctly for the working set you have. Then the working set grows. More data, more indexes, more of the table getting touched by day-to-day queries. The pool that comfortably held everything last year now holds most of it, then some of it, and the cache hit rate slips a little at a time. Nothing alerts you, because there's no failure, just a gradually rising share of reads coming off disk and a database that feels heavier under load. This is performance drift, and the buffer pool is one of the first places it shows up.
Where Releem fits
Sizing the buffer pool once is straightforward. Keeping it right as your data grows, your node resizes, and your query patterns shift is the part that quietly slips. That's what Releem is for.
Running as an add-on inside your Enscale environment, Releem watches buffer pool behaviour alongside the rest of your configuration and workload, and tells you when the pool has fallen out of step with the working set, and what to change. It's trained machine learning, not an LLM, so recommendations come from real patterns in your database rather than predicted text, with no hallucinated fixes. Applying a change is your call: Releem recommends the fix and tells you why, and you apply it yourself, in a click in the dashboard or with your own database tools, once you've read it. Manual review is the default and how we'd recommend running it, and if you later decide you want Releem applying routine changes for you, that's your decision to make. And the longer it runs, the more its advice reflects your specific environment and the adjustments that have already worked for you.
Frequently asked questions
What should innodb_buffer_pool_size be set to?
Generally 50% to 75% of the memory available to the database node, up to around 80% on a dedicated node with 8 GB or more. Always leave 1 to 2 GB for the operating system, and never size the pool so large that the node starts swapping, which cancels out the benefit entirely.
How do I check if my InnoDB buffer pool is big enough?
Look at your cache hit rate. Compare Innodb_buffer_pool_reads (disk reads) against Innodb_buffer_pool_read_requests (memory reads) from SHOW GLOBAL STATUS. A healthy pool keeps disk reads to a tiny fraction of the total. SHOW ENGINE INNODB STATUS also reports a hit rate directly, and a rising Innodb_buffer_pool_wait_free (queries waiting for a free page) is a genuine sign the pool is short of memory. Innodb_buffer_pool_pages_free naturally sits near zero once the pool is warm, so it isn't a reliable pressure signal on its own.
Can I change the InnoDB buffer pool size without restarting MariaDB?
Yes. SET GLOBAL innodb_buffer_pool_size resizes the pool online in the background. That change doesn't survive a restart, though, so also set innodb_buffer_pool_size in your MariaDB configuration file to make it permanent.
Why does buffer pool tuning drift in Enscale?
Because the right size depends on the memory allocated to your database node, and that changes when you scale the node. People resize resources and forget to revisit the pool, so it stays sized for a node that no longer exists. Working set growth compounds it: as more data gets touched by everyday queries, a pool that once fit everything gradually stops fitting.
Is a bigger buffer pool always better?
No. Beyond the point where your working set fits comfortably in memory, extra size gives little benefit, and sizing it so large that the node swaps actively hurts performance. The goal is to fit the working set with headroom left for the OS, not to maximise the number.
If your cache hit rate is slipping and reads are drifting to disk, your buffer pool has likely fallen behind your workload. Releem watches for exactly that and tells you what to change, while you keep the final say.
See how Releem works on Enscale, and install it on your database node →
Already an Enscale customer and ready to go? Install Releem now →
