Thank you for visiting the Rackspace Community
The The Community is live! Post new content or topics so our teams can assist.

Please contact your support team if you have a question or need assistance for any Rackspace products, services, or articles.

How to size database max connections with openstack

This question is answered.

We are implementing a private openstack environment, and have 3 controllers, with more compute nodes in the near future. We have glance, nova, cinder, neutron, and keystone. We have increased our database max connections from the default of 100 to 300, but still are running out of connections. We can increase that number further, but want to know if there is a reasonable formula to use. I know that all the services create worker processes, and it seems to be related to the number of cpus. For instance, one one server, we have 26 glance-registry, and 26 glance-api processes. And that is just one service.

Does anyone know of a reasonable formula or sizing document? maybe something like #cpus X 5 x number of glance controllers (just for glance connections).   Currently, looking at my database connections I have:

29 glance, 32 cinder, 130 nova, 23 neutron, and 11 keystone connections active on the db server. Any ideas on proper sizing of db connections?

Verified Answer
  • Hello Jim,


    Thank you for reaching out to us regarding this. OpenStack definitely uses quite a number of database connections and so therefore the number will need to be higher than what one would normally consider sufficient.

    You can find the following information which eludes to the formula we use here in our upstream Rackspace Private Cloud powered by OpenStack deployment:

    https://github.com/openstack/openstack-ansible/blob/master/playbooks/roles/galera_server/templates/my.cnf.j2#L48-L51


    # NOTE: The number of max connections is defined by ( host_vcpus * 100 ). This value # is the lowest integer based on the ansible facts gathered from every galera node. # Computing the connections value using the lowest denominator maintains cluster integrity # by not attempting to over commit to a less capable machine.

    Hope this helps out Jim!

    * This is based on MariaDB+Galera Cluster

All Replies