Как (динамически) определять оптимальное количество соединений db?

Question

Как вы планируете динамически настраивать максимальное количество подключений в пуле соединений с БД?

Я все же отказался от использования «жесткого кодированного» (конфигурационного файла, но все еще) количества подключений. Некоторое время больше соединений обеспечивает лучшую производительность. В другие времена меньшее количество соединений делает лучшую работу. Какое измерение вы бы использовали, чтобы определить, открыли ли вы слишком много соединений и на самом деле это вредно? Пожалуйста, имейте в виду, что я не могу просто «остановить мир», чтобы запустить тест производительности. Мне нужно что-то, что я мог бы использовать для своих собственных ответов на запрос (из которых у меня нет конкретных измерений - некоторые из них медленные, некоторые быстрые, и я могу заранее знать, что именно).
(обратите внимание, что я использую Java JDBC с базовыми драйверами DataDirect)

Этот подход используется где-то (и был ли он успешным)? Если нет, как бы вы решили решить «оптимальное количество подключений», когда вам нужно поддерживать как Oracle, так и MS SQL, как для нескольких версий, так и для запросов различаются по своей природе (индексированный поиск/неиндексированный поиск/сбор данных по объему/соответствие условий (индексированные и не индексированные, с подстановочными знаками и без них))?

[Я знаю, что это похоже на optimal-number-of-connections-in-connection-pool вопрос, но я спрашиваю о динамической конфигурации, когда он спрашивает о статическом]

Answer 1

закрытие отсутствует. Мы закончили тем, что использовали максимальное максимальное значение, и это, похоже, не сильно беспокоило БД.

Answer 2

Если очередь пользователи ждать бесплатного подключения к базе данных, они ждут на что-то неизвестным или искусственно введенным.

Если вы предоставите им доступ к базе данных, вы, по крайней мере, узнаете, с каким ресурсом ведется борьба (если есть). Например, если это дисковый ввод-вывод, вы можете перемещать файлы для распространения активности против большего количества или разных дисков или покупать некоторые SSD или больше памяти для кеша. Но, по крайней мере, вы знаете, что такое узкое место, и можете принять меры для его решения.

Если есть какой-либо ресурс запроса или обслуживания, вы должны заглянуть в диспетчер ресурсов для разделения/дросселирования этих сеансов.

Возможно, вы также захотите закрыть неиспользуемые сеансы (так что у вас может быть максимум 500 сеансов за обедом, но до 50 ночных часов, когда выполняется несколько больших пакетных заданий).

Answer 3

Вам нужен бесплатный проходной пул, который автоматически настраивается в зависимости от нагрузки. Таким образом, он должен иметь: - 1) Минимальный размер: 0 2) Максимальный размер: согласно конфигурации ур-БД 3) приращение на 1, если доступных подключений нет в наличии 4) отказаться от соединения, если оно idel для X (настроено время) секунд 5) Пул соединений должен освободить заброшенные соединения.

С учетом этих настроек пул соединений должен управлять динамическим числом соединений на основе нагрузки.