How to let workers share a common DB connection pool in Openstack Nova?

Question

as i know, in openstack nova system, DB connection is managed by Oslo_db which backend is SqlAlchemy

Let's us use nova-api as an example: Each worker would open their own exclusive DB connection pool. Where max_pool_size(or api_max_pool_size) decided the number of persistent connection, and max_overflow(or api_max_overflow) rule the max instantaneous connections that a worker can request.

In massive senario, we may increase the # of worker or # of nova-api to improve the max-request-handle-capability. It can cause waste of persistent connection (in steady state, we may have a lot of unused persistent connection, and other components like nova-conductor would be effected). I see that balancing between max_pool_size and # of worker may be a possible way to cope this problem. But, I was wondering that is there any possible way to let all the workers to share a common DB connection Pool, but start their own exclusive connection pool? In this way, we could significantly improve the usage of DB connections, and leave the connection space for other component

Example: exclusive connection pool(current secnario):

# of nova-api = 10
# of worker worker = 6
max_pool_size = 5
api_max_pool_size = 5

# of steady connection we may occupy from DB = 10 * 6 * (5+5) = 600
Suppose that DB would allow 1000 connections in the same time, 600 idle conn would be horrible for the whole system. 

common connection pool

# of nova-api = 10
# of worker worker = 6
max_pool_size = 5
api_max_pool_size = 5

Since in this ideally senario, workers share a common conn pool, so we pop off the workers number and would get: 
number of steady connection we may occupy from DB = 10 * (5+5) = 100

Again, i wouldn't expect that adjusting the # of workers or max_pool_size to improving the usage of connections. Is there any possible to make workers share a common conn pool

MANY THANKS TO THOSE PEOPLE WHO SHARE ANY PRACTICES OR IDEA HERE!

Answer 1

Each of the workers is a separate python process in a separate address space. So they cannot share database connections.

Besides:

1. 600 (or is it 80?) is not a concerning number of database connections. My guess is that it is just a few MB of RAM.
2. You would need a pretty heavy workload of Nova requests to cause the 10 Nova API instances with 5 workers to fully populate their connection pools.

So unless you have clear evidence that you actually do have ~600 DB connections in practice, AND that they actually are consuming a lot of resources, this sounds like an unnecessary optimization.