| 2016-01-18 16:27:22 |
Roman Podoliaka |
description |
In oslo.service we default to 1000 greenlets in the pool for a WSGI server:
cfg.IntOpt('wsgi_default_pool_size',
default=1000,
help="Size of the pool of greenthreads used by wsgi")
Which means up to $wsgi_default_pool_size HTTP requests will be processed concurrently by 1 fork of an OpenStack API service.
It turned out that this does not play well with oslo.db defaults for a pool of DB connections, which default to SQLAlchemy settings, which only allow to have up to 5 connections in pool and 10 overflow (will be closed once returned to the pool).
With such defaults it's easy to start seeing timeout errors (SQLAlchemy gives up waiting on a connection to be available from pool/overflow after 30s by default) in service logs even with moderate concurrency.
For DB oriented services (most of OpenStack APIs) we should decrease the number of greenlets in pool and increase max_overflow value for DB connections. |
In oslo.service we default to 1000 greenlets in the pool for a WSGI server:
cfg.IntOpt('wsgi_default_pool_size',
default=1000,
help="Size of the pool of greenthreads used by wsgi")
Which means up to $wsgi_default_pool_size HTTP requests will be processed concurrently by 1 fork of an OpenStack API service.
It turned out that this does not play well with oslo.db defaults for a pool of DB connections, which default to SQLAlchemy settings, which only allow to have up to 5 connections in pool and 10 overflow (will be closed once returned to the pool).
With such defaults it's easy to start seeing timeout errors (SQLAlchemy gives up waiting on a connection to be available from pool/overflow after 30s by default) in service logs even with moderate concurrency.
For DB oriented services (most of OpenStack APIs) we should decrease the number of greenlets in pool and increase max_overflow value for DB connections.
More context: http://lists.openstack.org/pipermail/openstack-dev/2015-December/082717.html |
|
