Comment 5 for bug 1744412

The connection pool tuning values apply to the configuration *per* worker, that is, assuming a "worker" here is a Python process (e.g. fork, has it's own PID). So the number of connections here is not related to the number of "workers" (again, assuming "worker" is a python process, and not a thread or greenlet) - it has to do with the concurrency inside of a single worker.

What the number *is* related to is how many concurrent requests may be sent to a single worker at a time. I wrote a long email about this in [1] which is referring to how openstack services at that time were all based on eventlet and all were set up to allow 1000 greenlets per process, meaning as many as 1000 requests could be sent to a single process at a time which will definitely bring forth this error.

I'm not up to speed on which services are using eventlet vs. mod_wsgi w threads vs. other, however, what's important here is the number of concurrent requests a single process can handle. If neutron is still on eventlet and using greenlets, the number of greenlets should be tuned way down and the number of possible connections tuned up to match the number of greenlets.

Background on what the connection pool error means is at [2], I recommend reading it completely to gain further understanding of this issue.

[1] http://markmail.org/message/r45i4ifnpnvgprpu

[2] http://docs.sqlalchemy.org/en/latest/errors.html#queuepool-limit-of-size-x-overflow-y-reached-connection-timed-out-timeout-z