mysql charm assumes the entirety of available memory belongs to it

Bug #1346698 reported by Paul Collins
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
mysql (Juju Charms Collection)
New
Undecided
Unassigned

Bug Description

I'm working with a Juju environment that has a number of services deployed to LXC containers on the same physical machine, a so-called "smooshed" deployment of OpenStack. The machine in question is 64-bit and has 32G of physical memory.

This environment has been up and running for some time and we've gradually deployed a few more services to this same machine. Today I discovered that mysqld (without which OpenStack does not function) was not running and would not start because, per /var/log/mysql/error.log, it could not allocate the innodb buffer pool:

140721 21:41:14 InnoDB: Initializing buffer pool, size = 22.0G
InnoDB: mmap(24141627392 bytes) failed; errno 12
140721 21:41:14 InnoDB: Completed initialization of buffer pool
140721 21:41:14 InnoDB: Fatal error: cannot allocate memory for the buffer pool
140721 21:41:14 [ERROR] Plugin 'InnoDB' init function returned error.
140721 21:41:14 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140721 21:41:14 [ERROR] Unknown/unsupported storage engine: InnoDB
140721 21:41:14 [ERROR] Aborting

As a naive user of the mysql charm, I was surprised both that it fell over and that innodb_buffer_pool_size was set to such a large value for an installation that will almost certainly never exceed a handful of gigabytes of data in total.

Reading through the charm's code, I can see how the value of 22G was arrived at: it's based on the default value for dataset-size of 80%, scaled against the 32G of memory in the system, with a few twiddles on top.

We've adjusted the charm's configuration in our deployment to reduce the size of the buffer pool, but perhaps the charm can learn to cope with such deployments more gracefully in its default configuration somehow?

(However, adjusting the charm configuration via juju did not seamlessly solve the problem. Before the charm updated my.cnf, it triggered a package upgrade, whose success depends on mysql starting up successfully, which of course it could not, and so the service unit dropped into an error state until I logged in, fixed my.cnf, completed the upgrade, and juju-resolved the errored unit.)

Please let me know if I should supply additional information or clarify anything.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.