У вас при любой нагрузке лимит конекшинов на постгресе до

100? вы все регулируете пгбаунсером?

у меня примерно 2000 конекшинов от бэкэнда. как мне максимально правильно настроить пгбаунсер и постгрес?

если мне не изменяет память > 100 нельзя в PSQL и в DB2 такое же ограничение

В идеале, max_connections бессмысленно делать больше числа доступных физических ядер процессоров сервера.

Это неверно. Указать можно сколько угодно, и оно честно отработает. Какие при этом возникнут проблемы - это второй вопрос

Если 90% из них 90% времени простаивают, то вполне себе полезно.

Это неверно. Если оптимизировать общую пропускную способность (скорость), то параллелизм должэн забить все устройства до насыщения самого ограничивающего. К количеству процэссоров это часто имеет очень опосредованное отношэние. И это число чаще всего заметно большэ количества процэссоров.

Я ж говорю, в идеале. Простой 9 бэкэндов из 10 в 90% говорит лишь об одном - плохой архитектуре решения.

Ну так сделайте max_connections равным 100000 и забьются все ядра и будет суперсервер, наверное. 😁

Каждый бэкэнд ложится на физическое ядро. Из этого, соответственно, мои выводы.

Хорошая шутка. Почти смешная.

У вас десять условных кассиров в условной 1С держат десять сессий и не успевают нагрузить пару четырёхгигагерцовых ядер. Где архитектурная ошибка?

Эти выводы довольно безосновательны и несоответствуют типичным результатам нагрузочного тэстирования.

Я ж говорю, о том, к чему нужно стремиться в идеале. Для такого детского случая, как Вы сейчас привели, в постгресе по дефолту стоит max_connections равным 100, как раз потому, чтобы большинство кассиров было довольно. Но человек то спрашивал про кейс с max_connections 2000. Т.е. его кейс скорее о хороших нагрузках, для которых и придумали пулы, вроде баунсера, хотя, в идеале, такой пул должен быть в постгресе, и над его реализацией работает уже давно К. Книжник, если я не ошибаюсь.

Хехе. Когда на сервере N ядер, то установка max_connections больше, чем N - это либо самообман, либо случаи, вроде упомянутых Романом - 10 кассиров кое-как работают с бд без загрузки последней.

В реальности бОльшая часть задач СУБД — io-bound. Потому, как минимум, базе надо забить очереди дисков. Которых во-первых много, во-вторых до них можэт быть приличный round-trip в десятки микросекунд (если это SAN какой-нибудь). При этом, когда 50 бэкэндов ждут своих данных от дисков в полёте — всё равно жэлательно, чтобы задачи для дисков вычислялись. Есди при равномерной нагрузке у нас 100% нагрузка дисков требует 20% загрузки CPU — то получается, что требуется ещё 1/5 от количества процэссоров. Примерно та жэ ситуацыя с загрузкой шыны памяти (только мониторить её сложнее, чем диски и процэссоры). В общем, в большынстве ситуацый надо заметно большэ воркеров, чем голов ЦПУ.

Во сколько раз больше? Каковы Ваши рекомендации?

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

Соглашусь. Но в идеале max_connections равен числу ядер, без всякого тестирования. Если речь идёт о нагрузках, то лучше перестраховаться и не задирать max_connections выше этого.

Ну, то есть можно конечно представить некоторые рекомендацыи там 15 на каждый hdd, 5 на ssd, плюс домножыть round-trip на iops, плюс по числу голов.... Но я ужэ говорил — многое зависит от нагрузки, многое — от расположэния данных. К тому жэ то, что я описал — это бонусы параллелизма. Ещё более богатая тема — его недостатки. Вымывание кэшэй, бесплодное ожыдание блокировок, ... Потому оцэнивать это очень полезно, но хорошый результат даёт эксперимент.

Ну, если вы выбрали себе такой идеал — то кто я такой, чтобы с ним интэрферировать. Но идеала всё равно не бывает, так что уж его мусолить. Базы данных у нас те, которые даны в ощущениях, и жэлезо тожэ.

> В реальности бОльшая часть задач СУБД — io-bound. [citation needed] Т.е. откуда "статистика"? > Потому, как минимум, базе надо забить очереди дисков. Потому как вот это выглядит как "кто-то удачно сэкономил на железе", IMHO. ;) > В общем, в большынстве ситуацый надо заметно большэ воркеров, чем голов ЦПУ. В этих ситуациях уже нужно "спасать" перегруженную СУБД, а крутить max_connections и т.п.

Это потому идеал, потому что логичен и очень просто объясняется безо всяких экспериментов и танцев с бубнами. Буквально на пальцах.

Ниоткуда статистика особенно. Так, опыт решэния проблем с СУБД. Последний абзац нераспарзил.

IMHO, большая часть таких "опытов" с успехом заменяется "just buy the damn RAM!". ;) > Последний абзац нераспарзил. Я про ситуации, "когда 50 бэкэндов ждут своих данных от дисков в полёте".