2014-12-11 1 views
9

Я использую pgbouncer в режиме транзакции &, пытаясь разрешить около 500 активных транзакций. Цель состоит в том, чтобы просто подчеркнуть проверить настройкуКак увеличить пропускную способность соединения для pgbouncer?

Текущая настройка: [ 'п' клиентов ---> 1 pgbouncer ----> 1 Postgres]

Я заметил, что моя транзакционные/вторая (ТПС) значительно уменьшается, когда я использую pgbouncer вместо прямого подключения к postgres.

Для того же набора к операции (через pgbench)

  • Прямые соединения => 10k (ТПС) appx

  • pgbouncer подключения => 3k (ТПС) appx

Есть ли какая-либо конфигурация в pgbouncer, которую необходимо настроить, чтобы обеспечить лучшую производительность?

Я понимаю, что pgbouncer - однопоточное приложение, но он хотел бы настроить его до самого лучшего. Ниже моя конфигурация pgbouncer:

pgbouncer.ini

pool_mode = transaction 
server_reset_query = 

# Time outs 
server_lifetime=6000 
server_idle_timeout=0 
server_connect_timeout=30 


#pool configuration 
max_client_conn=10000 
default_pool_size=500 
pool_size=500 

##other 
pkt_buf=4096 
server_login_retry=2 

Единственное приложение, я могу видеть, заключается в использовании нескольких pgbouncers, чтобы указать на тот же сервер БД.

UPDATE

при выполнении теста:

загрузка процессора: 30% appx

использования диска: 40% appx

Наблюдение: многие операции в 'холостом' состоянии

ИСПЫТАТЕЛЬНЫЕ ДЕТАЛИ:

10 машина, выступающая в роли клиентов, выполняющих запрос на запуск pgbench на сервер БД.

Команда: pgbench -h -p 6541 -c 512 -j 16 -f pgbench_SchemaScript.sql -T 360 -U Postgres тест

pgbench_SchemaScript.sql

\setrandom delta 0 100000 
insert into t1.emplog values(nextval('t1.employeeSeq'),:delta); 

1 сервер БД с Установлен pgbouncer (16core, 24 Gb RAM)

+0

Прежде чем что-либо изменить, я бы проверил использование процессора pgbouncer. 10000 клиентских подключений очень много, и это может быть слишком много для однопоточного приложения. 500 активных подключений на сервере PostgreSQL также много, вам нужно какое-то серьезное оборудование для высокой производительности. –

+0

Использование процессора для этой коробки составляет около 30% при выполнении теста. Коробка имеет 16 ядер и 24 ГБ оперативной памяти. Я замечаю, что использование диска также составляет около 40%. При использовании pgbouncer я замечаю много «незанятых» транзакций, и я считаю, что это вызывает низкие tps, но я не уверен, как их избежать. – jayanth88

+0

Простаивайте, когда у вас 10000 клиентов, которые должны быть заняты, это не хорошо. Какие тесты вы используете? Все транзакции закрыты, когда вы закончили с одним тестом? Если нет, это может вызвать задержку, поскольку соединение еще не доступно для другого клиента. Как процессор, так и диск должны повышаться до 100% или, по крайней мере, приближаться к 100%. –

ответ

0

Решение (частичное): Увеличение приоритета процессора pgbouncer с renice.

По умолчанию Linux-планировщик является круговым, и он голодает pgbouncer, потому что он обрабатывает все процессы одинаково - и сотни процессов postgres перегружают один процесс pgbouncer.

0

Я знаю, что это старый вопрос, но у нас была аналогичная проблема, и мы просто запускаем больше pgbouncers в Docker на разных портах против одной и той же базы данных, и это работает нормально. Таким образом, вы можете иметь разные очереди из разных приложений в отдельных экземплярах pgbouncer.

 Смежные вопросы

  • Нет связанных вопросов^_^