Размер пула соединений приложений Rails, исключая проблемы с максимальным размером пула

Я запускаю приложение JRuby on Rails. Я часто вижу это в моих журналах:

The max pool size is currently 5; consider increasing it

Я понимаю, что могу увеличить максимальный размер пула в моей конфигурации, чтобы решить эту проблему. Проблема, которую я ищу, - это понять, каково оптимальное число. Я стараюсь избегать проблем, связанных с подключением. Очевидно, что установка этого числа на что-то нелепое не будет работать.

Существует ли общий протокол для определения оптимального размера пула приложений вашего приложения?

Ответ 1

Из здесь,

Оптимальный размер пула потоков зависит от количества доступных процессоров и характера задач в рабочей очереди. В N-процессорной системе для рабочей очереди, которая будет полностью выполнять задачи, связанные с вычислением, вы обычно достигнете максимального использования ЦП с пулом потоков из N или N + 1 потоков.

Для задач, которые могут дождаться завершения ввода-вывода - например, задачи, которая считывает HTTP-запрос из сокета, - вы хотите увеличить размер пула за пределы количества доступных процессоров, поскольку не все потоки будет работать во все времена. Используя профилирование, вы можете оценить отношение времени ожидания (WT) к времени обслуживания (ST) для типичного запроса. Если мы будем называть это отношение WT/ST для N-процессорной системы, вы должны иметь потоки N * (1 + WT/ST), чтобы полностью использовать процессоры.

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

Итак, профилируйте ваше приложение, если ваши потоки в основном связаны с cpu, затем установите размер пулов потоков на количество ядер или количество ядер + 1. Если вы тратите большую часть своего времени на ожидание завершения вызовов базы данных, экспериментировать с довольно большим количеством потоков и посмотреть, как приложение работает.