Установил pgbouncer наконец. Устанавливал через докеры сначала, различные образы, но

Question

Установил pgbouncer наконец. Устанавливал через докеры сначала, различные образы, но

их простая настройка чуть из себя не вывела :) В итоге установил его на отдельном сервере и связал с базой по внутреннему IP. Все настройки pgbouncer'a были стандартными за исключением: pool_mode=session, default_pool_size=2000, max_client_conn=2000, если я всё правильно понял из источников. Убрал пул из SQLAlchemy, соединил её с pgbounce и вроде всё работает, но не совсем так, как ожидалось. Тестировал различные конфигурации воркеров и вот что получилось. Ниже будет график из Rabbitmq по обработке сообщений в очереди. И я сейчас не понимаю, где искать затуп, который случился.

(1) — поднято 10 машин (2 vCPU, 1GB RAM), на каждой из них работает воркер со следующими конфигурациями: 1 процесс с 1 потоком (в дальнейшем -p 1 -t 1). Скорость обработки сообщений вы видите на графике (отрезок (1)). Всё супер стабильно, скорость отличная. (напомню, что при запуске воркера на домашней машине с параметрами -p 1 -t 1 скорость обработки была ~1 сообщение/с). На клауде с такими параметрами обрабатывалось 15 сообщений/с.

(2) — поднятно 33 машины (2 vCPU, 1GB RAM), на каждой из них работает воркер с такими же конфигурациями что и в предыдущем ((1)) случае. Опять же, скорость выросла как и ожидалась, она стабильна. Всё отлично.

(3) — поднята 1 машина (2 vCPU, 1GB RAM). На неё работает воркер с параметрами: 1 процесс 50 потоков. Скорость, как вы видите, существенно отличается даже от случая (1), где в сумме было поднято 10 потоков. Во-первых, скорость слишком нестабильная, число обработки скачет от 60 до 120, во-вторых, 50 потоков > 10 потоков, поэтому ожидается скорость больше чем была, не так ли? Это проблема непосредственно с pgbouncer, или всё-таки с воркером (в чём я на данный момент сомневаюсь, ибо до этого количество указанных потоков прямо соответствовало скорости обработки сообщений)

#backend #devops #pgsql #programming #russian

0

23.02.2021

5 ответов

12 просмотров

Mooner Автор вопроса

Dmitriy Sviridov
Немного не по теме, наверное, но у меня вопрос. Ес...

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

0

23.02.2021

Dmitriy Sviridov

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

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

0

23.02.2021

Mooner Автор вопроса

Dmitriy Sviridov
Ок. Так почему вы считаете, что увеличение количес...

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

0

23.02.2021

Dmitriy Sviridov

Mooner
Один воркер при использовании пула соединений из s...

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

0

23.02.2021

Dmitriy Sviridov · Accepted Answer

Немного не по теме, наверное, но у меня вопрос. Если вы на каждой машине запускаете ровно один воркер (1 питон-процесс), то зачем вам 2 vCPU на них, учитывая, что по сути задействуется лишь одно ядро? 1 питон процесс два ядра загрузить не может. Или я что-то не так понял

172 похожих чатов

Установил pgbouncer наконец. Устанавливал через докеры сначала, различные образы, но

5 ответов

Похожие вопросы