Closed nobuto-m closed 2 months ago
@nobuto-m , you are on absolutely correct. Created PR with the fix
https://github.com/canonical/mysql-operator/pull/429#discussion_r1544142953
Essentially this is (at least) a 3-parameter problem to me. The proposed logic is better than the current one since it can avoid overcommitting memory to 175%. However, keeping limiting user-configurable parameters to 1 doesn't solve the fundamental challenges.
At this moment, we don't allow configuration other than the parameter "A" in the diagram. I assume that the
mysql.py
logic is shared between the machine charm and the k8s charms so the parameter "A" is determined either by the total amount of physical memory, memory_limit charm config, or pod resource limit. But no other parameters about the memory allocation can be supplied by an user.When an user needs to bump the max_connections we will have to bump the memory requirement 4 times unnecessarily since there is no way to tell the charm to change the ratio of the memory allocation (75% innodb pool size + 25% max_connections).
For example with MySQL use cases as the backend of OpenStack deployment, we know that it requires a few thousand max connections to cover the distributed (and micro service-ish) control plane services and the multiple workers of each micro service, but 8GB of innodb buffer pool size is more than enough.
Let's say to have max_connections=4,000, 64 GB of the instance is more than enough (4,000 connections 12MB + 8GB innodb buffer pool size = 56GB). However, with the fixed ratio, we need 200GB machine (4,000 connections 12MB * (75+25)% / 25% = 192GB).
I cannot think of a better way than moving away from a single parameter.
Hi @nobuto-m , indeed it's a very compelling argument. By concept the operator is trying to reach a close to optimal self calculated defaults and for sure we still need to sophisticate it further. I will take your case forward, given it's impossible to satisfy every use case.
(there is question mark in the title since I'm not 100% sure yet before running a stress test)
Steps to reproduce
Expected behavior
mysqld should allocate memory for
innodb_buffer_pool_size
andmax_connections
within the amount of the physical memory available.Actual behavior
The charm writes the following config with 32GB memory system.
[/var/snap/charmed-mysql/current/etc/mysql/mysql.conf.d/z-custom-mysqld.cnf]
So it looks like innodbbuffer* tries to use ~23GB of memory at maximum and max_connections tries to use ~32GB of memory at maximum on the same 32GB memory.
https://github.com/canonical/mysql-operator/blob/8bf9fb36ce23b06f5b0838868a2ebe54486d912f/lib/charms/mysql/v0/mysql.py#L717-L727
Versions
Operating system: Ubuntu 22.04 LTS
Juju CLI: 3.4.0-genericlinux-amd64
Juju agent: 3.4.0
Charm revision: mysql 8.0/edge 210
LXD: 5.20
Log output
Juju debug log:
This is from an extra debug logging with by hand modification to add some traces.
Additional context