спасибо, можете дать ссылку, пожалуйста ?)

Фух, едва нашёл (в истории чата): https://t.me/postgis
(В сторону, мечтательно): Когда наши модераторы уже внесут в описание этого чата хоть что-то действительно полезное? ;)

👍👍👍

Меньше машину сделать нельзя, только с 2 vCPU

Ок. Так почему вы считаете, что увеличение количества потоков в питон приложении должно повысить производительность?

Один воркер при использовании пула соединений из sqlaclhemy (pool_size=50) и количеством потоков 50 обрабатывал на локальной машине 50 сообщений в секунду. После деплоя воркера с такими же параметрами в клауд, скорость обработки повысилась до ~130 сообщений в секунду.
А вот сейчас, при использовании pgbouncer (pool_size=2000, max_client_conn=2000, pool_mode=session) на локальной машине обрабатывается 25 сообщений в секунду, а при деплое воркера в клауд обрабатывается как случай (3) на графике выше

Я думаю, дело вообще не в боунсере совершенно. Скажите, а что там происходит вообще в этих воркерах? Может там асинхроннные операции, и потоки там нафиг не упали и подойдёт asyncio?

На данный момент разбираюсь только с одним воркером.
Который принимает на вход сообщение, проверяет, есть ли такое сообщение в базе, если нет, то записывает в базу, если есть, то ищет в сообщении ключевые слова, и отправляет в следующую очередь связку message_id и keyword

Это ж всё асинхронные операции. Зачем вам потоки?

Изначально выбирали для процессинга задач Dramatiq (https://dramatiq.io/)

В общем, я бы тогда вообще не заморачивался с потоками, а масштабировал бы процессами. 1 воркер = 1 процесс = 1 поток. Либо asyncio задействовал, но питоновские потоки я бы юзать точно не стал

Спасибо, подумаем над этим.
Но если возвращаться к исходному вопросу: с пулами из sqalchemy работало быстрее, чем с pgbouncer — можно тут что-то сделать с pgbouncer?

У вас долгие фоновые задачи, а каждая задача держит одно соединение?

Вот тут не подскажу. Дождитесь ответа от DBA, которые боунсер советовали. Возможно, с pool_mode надо шаманить

Не пробовали transaction pool_mode?

Ещё нет, но вот собирался менять

В принципе да, так и было, пока один воркер не был переписан под использование подключения только тогда, когда это надо было

В таком случае смысла в баунсере в режиме сессий мало

Есть мониторинги, по которым можно посмотреть сколько активных соединений с базой в среднем?

Да, можно