The issue with percona cluster is the 5.6 version of mysql defaulting to performance_schema=on [1] at server startup. This allocates all the memory that would be required to handle max-connections plus several other memory settings. See the mysql memory calculator [2] to see how this plays out.
With 5.5 this was not the an issue. We occasionally saw connection exhaustion in HA clouds with max-connections near 2000. The common practice became to set max-connections unrealistically high near 10k or 20k. In the move to 5.6 on Xenial this became a problem.
Discussed this with the team and the plan is to make performance_schema [1] configurable and default to off at startup in the percona cluster charm. This will get us 5.5 like behavior and avoid over committing memory based on max-connections.
The issue with percona cluster is the 5.6 version of mysql defaulting to performance_ schema= on [1] at server startup. This allocates all the memory that would be required to handle max-connections plus several other memory settings. See the mysql memory calculator [2] to see how this plays out.
With 5.5 this was not the an issue. We occasionally saw connection exhaustion in HA clouds with max-connections near 2000. The common practice became to set max-connections unrealistically high near 10k or 20k. In the move to 5.6 on Xenial this became a problem.
Discussed this with the team and the plan is to make performance_schema [1] configurable and default to off at startup in the percona cluster charm. This will get us 5.5 like behavior and avoid over committing memory based on max-connections.
Note this is somewhat of a duplicate of [3]
[1] http:// dev.mysql. com/doc/ relnotes/ mysql/5. 6/en/news- 5-6-6.html# mysqld- 5-6-6-performan ce-schema www.mysqlcalcul ator.com/ /bugs.launchpad .net/charms/ +source/ percona- cluster/ +bug/1600001
[2] http://
[3] https:/