2012-04-03 2 views
8

Я читаю о пуле соединений SQLAlchemy, который по умолчанию имеет 5 подключений и по умолчанию переполняется до 10.Что происходит, когда пул соединений исчерпан?

Если количество кешированных соединений превышено, что происходит? Являются ли последующие запросы поставленными в очередь до тех пор, пока не будет доступно бесплатное соединение или не будет создано новое соединение, не входящее в пул?

Кроме того, что происходит с неиспользуемыми соединениями, когда пул «переполнен» до максимального значения по умолчанию 10? Отключают ли эти соединения по умолчанию (как и в стандартном пуле), или они выпущены более агрессивно, чем стандартный пул?

ответ

13

Вы здесь: QueuePool, который управляет соединениями с базой данных для лучшей производительности. Он делает это, открывая незанятые соединения, если вы захотите повторно использовать их позже. Количество подключений, которое будет открыто, равно pool_size = 5 (по умолчанию). Если вы откроете шестое соединение, одно из соединений в очереди будет закрыто, если оно не работает. Если ни один не работает, QueuePool откроет дополнительные, до max_overflow = 10 (по умолчанию). И еще, и вы получите сообщение об ошибке. Однако оба этих параметра настраиваются. Установите pool_size = 0, чтобы иметь неограниченное количество открытых соединений. The source is here

+0

pool_size = -1 для неограниченного использования. – zzzeek

+1

hmm, в ссылке на документы, посмотрите на QueuePool .__ init__, docstring говорит, что «' 'pool_size'' может быть установлен в 0, чтобы указать ограничение по размеру» –

+0

oh вы правы Я смотрел pool_recycle – zzzeek

4

SQLAlchemy docs Per,

Когда число извлеченных соединений достигает размера, установленный в pool_size, дополнительные соединения будут возвращены до этого предела. Когда эти дополнительные подключения возвращаются в пул, они отсоединяются и отбрасываются. Из этого следует, что общее количество одновременных подключений пула будет pool_size + max_overflow, а общее количество «спальных» соединений, которые пул позволит, составляет pool_size.

Так что да, переполненные соединения освобождаются более агрессивно, чем обычно спящие соединения.

Если вы на самом деле смотреть на источники QueuePool._do_get(), вы увидите, что она поднимает TimeoutError числа соединений составляет размер пула + переполнение, и соединение не возвращается обратно в бассейн сразу же после connect() называется.

Смежные вопросы