Juju Charms Collection
percona-cluster package

feature: provide config option for control of performance-schema

Bug #1590430 reported by Nobuto Murata on 2016-06-08

This bug affects 2 people

Affects		Status	Importance	Assigned to	Milestone
	OpenStack Percona Cluster Charm	Fix Released	Wishlist	Unassigned	OpenStack Percona Cluster Charm 17.02
	percona-cluster (Juju Charms Collection)	Invalid	Wishlist	Unassigned

Bug Description

When setting the same "innodb-buffer-pool-size" value as 512M, xenial container uses +600MB memory compared to trusty.

[trusty container]
$ lxc info juju-114e9a6e-b047-4ea6-8380-eb95ea48ef4c-machine-0 | grep Memory
  Memory usage:
    Memory (current): 689.59MB
    Memory (peak): 744.98MB

[xenial container]
$ lxc info juju-114e9a6e-b047-4ea6-8380-eb95ea48ef4c-machine-1 | grep Memory
  Memory usage:
    Memory (current): 1.31GB
    Memory (peak): 1.46GB

$ juju status
[Services]
NAME STATUS EXPOSED CHARM
percona-cluster-trusty active false cs:~openstack-charmers-next/trusty/percona-cluster-214
percona-cluster-xenial active false cs:~openstack-charmers-next/xenial/percona-cluster-202

[Relations]
SERVICE1 SERVICE2 RELATION TYPE
percona-cluster-trusty percona-cluster-trusty cluster peer
percona-cluster-xenial percona-cluster-xenial cluster peer

[Units]
ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE
percona-cluster-trusty/0 active idle 2.0-beta7 0 10.0.8.80 Unit is ready
percona-cluster-xenial/0 active idle 2.0-beta7 1 10.0.8.54 Unit is ready

[Machines]
ID STATE DNS INS-ID SERIES AZ
0 started 10.0.8.80 juju-114e9a6e-b047-4ea6-8380-eb95ea48ef4c-machine-0 trusty
1 started 10.0.8.54 juju-114e9a6e-b047-4ea6-8380-eb95ea48ef4c-machine-1 xenial

Revision history for this message

Nobuto Murata (nobuto) wrote on 2016-06-08:

bundle.yaml Edit (578 bytes, text/plain)

This is the bundle I used.

Revision history for this message

Nobuto Murata (nobuto) wrote on 2016-06-08:

hmm, it looks like the difference of the amount of page cache. Will look into more.

Revision history for this message

James Page (james-page) wrote on 2016-09-22:

This is likely due to differences in mysql between 5.5 and 5.6 on how memory allocation around the use of max_connections works; with performance_scheme enabled (the default), the server will allocate alot more memory on startup resulting in the increased footprint on xenial compared to trusty.

Revision history for this message

James Page (james-page) wrote on 2016-09-22:

https://bugs.mysql.com/bug.php?id=68514

Revision history for this message

James Page (james-page) wrote on 2016-09-22:

Example:

top -b -n1 | grep -w mysqld

600 connections:

13188 mysql 20 0 9.900g 1.127g 11436 S 0.0 7.3 0:01.38 mysqld

-1 (151 connections):

14611 mysql 20 0 9.823g 1.051g 11824 S 0.0 6.8 0:00.71 mysqld

-1 with performance_schema disabled (much more aligned with trusty):

15379 mysql 20 0 9885508 686784 11808 S 0.0 4.2 0:00.46 mysqld

Revision history for this message

James Page (james-page) wrote on 2016-09-22:

I guess we could provide an option to disable the performance schema to reduce memory consumption; but that's a nice to have IMHO.

summary:	- distinct memory usage in xenial compared to trusty deployment + feature: provide config option for control of performance-schema
Changed in percona-cluster (Juju Charms Collection):
status:	New → Triaged
importance:	Undecided → Wishlist

James Page (james-page) on 2017-02-23

Changed in charm-percona-cluster:
importance:	Undecided → Wishlist
status:	New → Triaged
Changed in percona-cluster (Juju Charms Collection):
status:	Triaged → Invalid

Revision history for this message

James Page (james-page) wrote on 2017-02-24:

commit e47c4ad13517996963867e6d6a4765a0a8aa29f4
Author: David Ames <email address hidden>
Date: Thu Jan 5 10:08:55 2017 -0800

Default performance schema to off

    The 5.6 version of mysql defauls to performance_schema=on at server
    startup. This allocates all the memory that would be required to
    handle max-connections plus several other memory settings.

    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 as the memory requirements for
    values that high are unrealistic.

    This change adds performance schema as a configuration option and
    defaults to off giving 5.5 like behavior. It also considerably
    updates documentation and highlights the need to carefully consider
    memory related configuration settings for production environments.

Make the amulet test python2 and python3 capable.

    Change-Id: Id01095ac2f73fa041b25b2602496a4c04a13e3ef
    Partial-Bug: #1654086
    Closes-Bug: #1600001