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

Question

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

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

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

[Я знаю, что это похоже на вопрос об оптимальном количестве соединений в пуле , но я спрашиваю о динамической конфигурации, пока он спрашивает о статической]

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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