[Bug 1578080] Re: percona cluster hits resource limits in HA Openstack cloud with xenial

Waldemar Hamm waldemarhamm at gmail.com
Mon May 23 13:48:02 UTC 2016


Great to hear. This bug will be fixed then I guess:
https://youtrack.jetbrains.com/issue/UP-6943

Thanks a lot!

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1578080

Title:
  percona cluster hits resource limits in HA Openstack cloud with xenial

Status in percona-xtradb-cluster-5.6 package in Ubuntu:
  Won't Fix
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Released
Status in percona-cluster package in Juju Charms Collection:
  Won't Fix
Status in systemd package in Debian:
  Fix Released

Bug description:
  I'm trying to deploy Mitaka Openstack using the 16.04 charms on Xenial
  using Juju 1.25.5 and MAAS 1.9.2, with as many components of Openstack
  being HA as possible.

  When deployed, after running for a while mysql (which is a 3 node
  cluster) starts refusing connections, and erroring:

    2016-05-03 01:25:28 13795 [ERROR] Error log throttle:         50
  'Can't create thread to handle new connection' error(s) suppressed

  When I look at systemd-cgtop, I can see it maxing out at 512
  connections.

  To get it going again I do a:

    $ sudo systemctl edit mysql

  and set:

    TasksMax=infinity

  Sometimes I even need to edit /etc/systemd/system.conf and bump
  DefaultTasksMax to 1024 or higher, depending on long its been left
  running.

  I've noticed that dropping worker-multiplier setting on nova-cloud-
  controller, neutron-api etc all help to reduce the load, but I still
  need to bump it up.

  Please let me know if you need any more information.

  SRU INFORMATION
  ---------------
  Impact: Introducing a default #thread limit of 512 broke an unknown set of services which regularly run many threads.
  Fix: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=fe4d9d3ba0 (essentially, revert the upstream commit that enabled it)
  Regression potential: Very low -- this just restores the pre-228 behaviour and does not impose any new restriction.
  Test case:
   - Pick some unit like cron.service or mysql.service that does not specify an explicit TaskMax= limit.
   - Check its TaskMax: systemctl show -p TasksMax cron.service
   - In current xenial this is "512", after the update it should be a very big number (maxint minus 1, which means "infinity")

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/percona-xtradb-cluster-5.6/+bug/1578080/+subscriptions



More information about the foundations-bugs mailing list