# innodb\_buffer\_pool\_size possibly not being used?

**URL:** <https://forums.percona.com/t/innodb-buffer-pool-size-possibly-not-being-used/367>\
**Category:** Other MySQL® Questions\
**Created:** [June 23, 2007, 5:46pm UTC](https://forums.percona.com/t/innodb-buffer-pool-size-possibly-not-being-used/367 "2007-06-23T17:46:12Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![jlederma](https://avatars.discourse-cdn.com/v4/letter/j/a8b319/32.png) [@jlederma](https://forums.percona.com/u/jlederma)\
**Post date:** [June 23, 2007, 5:46pm UTC](https://forums.percona.com/t/innodb-buffer-pool-size-possibly-not-being-used/367/1 "2007-06-23T17:46:12Z")

</div>

I’m trying to performance tune/debug performance on a mysql 5.0.27 install. All tables are innodb, and the machine is running centos4\_x86\_64 on a Dual Dual Core 2.6g (intel 5150) machine with 16g of ram. Using tools such as innotop I see disk reads in the 5k/s - 10k/s range and the db is not incredibly large. From the output of show innodb status below, I suspect that only 26M is being used for buffer\_pool cache instead of the 3G as directed in the conf file. Am I reading this wrong? Is there a way to tell what mysql believes its limits are?

Buffer related output from ‘show innodb status’

* * *

## BUFFER POOL AND MEMORY

Total memory allocated 26576648; in additional pool allocated 1048576  
Buffer pool size 512  
Free buffers 0  
Database pages 491  
Modified db pages 9  
Pending reads 0  
Pending writes: LRU 0, flush list 0, single page 0  
Pages read 23909121, created 240, written 29564  
7354.91 reads/s, 0.13 creates/s, 9.72 writes/s  
Buffer pool hit rate 992 / 1000

* * *

Innodb related section fix my.cnf:

#innoDB options

# Uncomment the following if you are using InnoDB tables

innodb\_data\_home\_dir = /var/lib/mysql/  
innodb\_data\_file\_path = ibdata1:4G;ibdata2:100M:autoextend  
innodb\_log\_group\_home\_dir = /var/lib/mysql/  
innodb\_log\_arch\_dir = /var/lib/mysql/

# You can set ..\_buffer\_pool\_size up to 50 - 80 %

# of RAM but beware of setting memory usage too high

#innodb\_buffer\_pool\_size = 1G  
innodb\_buffer\_pool\_size = 3G  
innodb\_additional\_mem\_pool\_size = 512M

# Set ..\_log\_file\_size to 25 % of buffer pool size

#innodb\_log\_file\_size = 128M  
innodb\_log\_file\_size = 512M  
innodb\_log\_buffer\_size = 128M  
innodb\_flush\_log\_at\_trx\_commit = 1  
innodb\_lock\_wait\_timeout = 50

default-storage-engine=innodb

---

<div class="post-metadata">

**Author:** ![Speeple](https://avatars.discourse-cdn.com/v4/letter/s/73ab20/32.png) [@Speeple](https://forums.percona.com/u/Speeple)\
**Post date:** [June 24, 2007, 9:35am UTC](https://forums.percona.com/t/innodb-buffer-pool-size-possibly-not-being-used/367/2 "2007-06-24T09:35:06Z")

</div>

Hi,

What is the combined size of your innodb tables?

Also note innodb’s buffers aren’t populated automatically.

For example, I have a 8Gb innodb buffer, and 6Gb of innodb based data. To load the data into the innodb cache when mysql starts I have a .SQL file with init SQL statements (my.cnf):

init\_file = /usr/local/mysql/var/init.sql

The queries in the init.sql file contain queries that require full table scans and helps populate innodb buffers and get the server chugging along optimially:

…  
SELECT COUNT(id) FROM speeple.news\_items;  
…

---

<div class="post-metadata">

**Author:** ![jlederma](https://avatars.discourse-cdn.com/v4/letter/j/a8b319/32.png) [@jlederma](https://forums.percona.com/u/jlederma)\
**Post date:** [June 24, 2007, 10:43am UTC](https://forums.percona.com/t/innodb-buffer-pool-size-possibly-not-being-used/367/3 "2007-06-24T10:43:00Z")

</div>

This is all fixed now, for those that stumble across this posting. This was escalated to a professional engagement with mysqlperformanceblog consulting, when Vadim quickly noticed that innodb settings go in the [mysqld] section, not the [mysql.server] section. Of course I didn’t include that part in my original post… Now the db is using 10G for its buffer\_pool cache and disk reads are in the 0-50 per second range. Thanks Speeple and especially Vadim.
