Размер пула: почему больше не значит быстрее

Команда видит, что база — узкое место, поэтому поднимает пул соединений с 20 до 100, ожидая примерно впятеро больше пропускной способности. Пропускная способность падает. Задержка лезет вверх, CPU базы прыгает, и работа, которую сервер реально заканчивает в секунду, идёт вниз. Они подняли единственное число, выглядевшее дросселем, и сделали всё хуже. Пул был не мал — он стал намного больше числа запросов, которые железо базы способно выполнить разом, и каждое лишнее соединение за этим пределом — не параллелизм, а конкуренция.

Больше соединений — не больше параллелизма

Кажется очевидным, что больше соединений значит больше конкурентной работы. Это не так, и причина физична. У сервера базы фиксированное число ядер CPU и фиксированное число дисковых шпинделей (или очередей SSD). В любой миг он способен реально выполнять лишь столько запросов, сколько у него ядер; всё прочее ждёт. Соединение, держащее запрос, не магически бежит — оно конкурирует за ядро, на котором побежать.

Поэтому открыв 100 соединений на 8-ядерной коробке, ты не получаешь 100 запросов разом. Ты получаешь 8 бегущих и 92 дерущихся за те 8 ядер, плюс все накладные на переключение между ними. Размер пула задаёт, сколько запросов может быть в полёте; железо задаёт, сколько может реально продвигаться. Когда первое число сильно превышает второе, разрыв — чистая трата.

Три налога раздутого пула

Каждое соединение за полезным числом не сидит тихо. Оно стоит тебе тремя способами разом:

• Переключение контекста. ОС нарезает много соединений по немногим ядрам по времени. Каждое переключение сбрасывает кеши CPU и стоит времени планировщика. Со 100 активными соединениями на 8 ядрах коробка тратит растущую долю CPU лишь на смену того, какой запрос бежит, вместо выполнения запросов.
• Конкуренция за блокировки и латчи. Конкурентные транзакции дерутся за блокировки строк, а внутренние латчи базы (буферный пул, WAL, таблицы блокировок) общие. Больше конкурентных соединений значит больше конкуренции на этих общих структурах — а конкуренция сверхлинейна, поэтому хуже растёт быстрее числа соединений.
• Память. В Postgres каждое соединение — форкнутый backend-процесс, держащий ~2–3 МБ базовой памяти, и хуже, work_mem выделяется на операцию на соединение. Запрос с тяжёлой сортировкой при work_mem = 16 МБ через 100 соединений может зарезервировать гигабайты; та же нагрузка на 10 соединениях не может.

Формула: маленькая, выведенная из железа

Известная рекомендация HikariCP превращает это в стартовую формулу:

соединения = (число_ядер × 2) + эффективное_число_шпинделей

Интуиция: пока один запрос ждёт дисковый I/O, другой может использовать освобождённое ядро CPU — поэтому хочется примерно вдвое больше ядер, чтобы держать их занятыми сквозь паузы I/O, плюс одно на каждый независимый диск, способный обслужить seek параллельно. 4-ядерный сервер с одним SSD даёт (4 × 2) + 1 = 9 соединений. Не 90. Число, максимизирующее пропускную способность, шокирующе мало, и измеренные бенчмарки это подтверждают: пул на ~10 часто бьёт пул на 100 на том же железе, заканчивая больше запросов в секунду при меньшей задержке.

Подбор размера — поиск точки насыщения

Формула — стартовая точка, не финальный ответ — у реальных нагрузок смесь CPU-bound и I/O-bound запросов, и правильное число находится измерением. Метод — поднимать конкурентность, следя за пропускной способностью и задержкой: пропускная способность растёт, затем выходит на плато (точка насыщения), затем падает, как конкуренция берёт верх. Лучший размер пула сидит на плоской вершине или чуть ниже — наименьший пул, достигающий пика пропускной способности. За ним ты покупаешь задержку без отдачи в пропускной способности, ровно поведение колена очереди из урока про пропускную способность, теперь движимое выбранным тобой пулом.