Is there a way to separate memory allocation for databases in mysql on the same server?
Say for database_1, we would like to allocate 20GB RAM,
and for database_2, 10GB RAM.
Is there any way this is possible.
Mysql: Separate memory for databases
MySQL
Related Solutions
First all take a look at the InnoDB Architecture (courtesy of Percona CTP Vadim Tkachenko)
InnoDB
Your status for the Buffer Pool says
Buffer pool size 1310719
That's your Buffer Size in Pages. Each page is 16K. That turns out 20G - 16K.
Please note the the following: You pushed data into the InnoDB Buffer Pool. What changed ?
Buffer pool size 1310719
Free buffers 271419 (It was 347984)
Database pages 1011886 (Is was 936740)
Old database pages 373510 (It was 345808)
Modified db pages 4262 (It was 0)
Also, note the difference between the Buffer Pool Size in Pages.
1310719 (Buffer pool size) - 1011886 (Database pages) = 298833
That's 298833 InnoDB pages. How much space is that ???
mysql> select FORMAT(((1310719 - 1011886) * 16384) / power(1024,3),3) SpaceUsed;
+-----------+
| SpaceUsed |
+-----------+
| 4.560 |
+-----------+
That's 4.56GB. That space is used for the Insert Buffer Section of the InnoDB Buffer Pool (a.k.a. Change Buffer). This is used to mitigate changes to nonunique indexes into the System Tablespace File (which all have come to know as ibdata1).
The InnoDB Storage Engine is managing the Buffer Pool's internals. Therefore, InnoDB will never surpass 62.5% of RAM. What is more, the RAM for the Buffer Pool is never given back.
WHERE IS THE 70.2% OF RAM COMING FROM ???
Look back at the output of mysqltuner.pl at these lines
[OK] Maximum possible memory usage: 22.6G (82% of installed RAM)
Key buffer size / total MyISAM indexes: 2.0G/58.7M
[--] Total buffers: 22.2G global + 2.7M per thread (151 max threads)
mysqld has three major ways of allocating RAM
- You set 20G of the InnoDB Buffer Pool
- You have 2G for MyISAM Key Cache
- The remaining 0.6G comes from 151 (max_connections) times (2.7M per DB Connection or thread). The 2.7M comes from (join_buffer_size + sort_buffer_size + read_buffer_size)
Any small spike in DB Connections will raise RAM past the 62.5% threshold you see for InnoDB.
MyISAM (Side Note)
What catches my eye is
Key buffer size / total MyISAM indexes: 2.0G/58.7M
Since you have so little indexes for MyISAM. You could set the key_buffer_size to 64M.
You do not need to restart mysql for that. Just run
SET GLOBAL key_buffer_size = 1024 * 1024 * 64;
Then, modify this in my.cnf
[mysqld]
key_Buffer_size = 64M
This will give the OS 2GB of RAM. Your VM will simply love you for it !!!
Give it a Try !!!
CAVEAT
Running FLUSH TABLES on InnoDB tables simply closes files against the .ibd files. This will not really push changes directly. The changes have to migrate its way through the pipes of InnoDB. This is why you see the spike in Modified db pages. The 4262 changed pages (66.59 MB) gets flushed when InnoDB's scheduless its flush.
To reduce the RAM used by each instance from ~450MB to 17MB this setting was required:
performance_schema=off
To fix the
InnoDB: Cannot allocate memory for the buffer pool
...the setting innodb_open_files=300 had to be changed to innodb_open_files=3000.
Related Question
- Mysql – Release MySQL Memory and Performance Tunning
- Mysql – Is MySQL Cluster just for in-memory databases
- Mysql using 10GB more in ps aux than in “Max MySQL memory”
- MySQL Performance vs. Memory
- Mysql – Cannot allocate memory for the buffer pool when using remote access MySQL
- MySQL is not releasing memory after memory tables are dropped
- MySQL using more memory than expected
Best Answer
I say not to do it because it usually leads to folly. If one database grows faster than the other, then it is starved while the other has spare space. This may hobble the overall system more than the original benefit you envisioned.
Another example: Having
/tmpon a separate filesystem. I hate to think how many times DBAs find queries crapping out, only to discover that their tiny /tmp fs was starved while the main disk was swimming in space.On the other hand, there are valid cases for splitting up things -- one disk is an old, slow, spinning drive, another is a fast, low latency, SSD. Or you add an extra drive, but it is not convenient to get the OS to see all the drives as one larger virtual drive. These involve spelling out what databases / tables / logs to put where -- and lead to the potential problem that I mentioned above.
If you are referring to RAM, then the general rule is to give most of RAM to
innodb_buffer_pool_size, then forget about RAM allocation. Only a few percent of RAM needs to be allocated for table cache, etc, etc. The buffer pool is used by all tables 'equally' -- that is on a roughly LRU basis.