|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
Добрый день. Ребят, кто бы что умного сказал по итогам такого эксперимента. Заранее благодарю. Приложение некий гибрид между OLTP и OLAP, система отчетности. Самые суровые запросы отдельно на реплике, но и на мастере бывают по 500-700мс запросы. Но в основном быстрые частые запросы. все серверы с конфигурацией 16 процессоров, HDD, 32GB ОЗУ. Centos 7 на вебе php 7.1 на БД мастер+реплика Postgres 9.5 shared_buffers 8gb max_connections 3000 work_mem = 2gb maintenance_work_mem = 8gb Работает 2тыс пользователей Решаемая проблема: большое количество коннектов на БД, около 500, и большое количество процессов 600-800, графики по нагрузке сервера БД очень неравномерные. Установил на мастер БД bgBouncer pool_mode = transaction max_client_conn = 5000 default_pool_size = 40 остальное по дефолту. В итоге графики коннектов, процессов, нагрузки на процессор стали более плавные без скачков. Количество коннектов на БД стало стабильно 120-150 вместо 500, процессов 400 вместо 700. Но веб сервер стал адски тормозить, а порой и просто уходит в 502, хотя ресурсов и на вебе и на бд достаточно и ОЗУ и процессора. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 11:49 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
Было по коннектам к БД без баунсера ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 11:50 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
Стало после установки баунсера, теперь графики idle и idle in transaction весело меняются местами ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 11:54 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
К БД в php настроено соединение через одного пользователя, все пользователи системы ходят к базе через него. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 12:03 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
kliff, 1)нужны графики от pgbouncer про wating/active/idle clients из show pools 2)по тому что я вижу на графиках базы у вас как раз случай автор'Установка больше чем 100-200 оправдана ТОЛЬКО в очень особых случаях и для кривых приложений которые с транзакциями некорректно работают.' "для кривых приложений которые с транзакциями некорректно работают." надо изучать откуда у вас столько idle in transaction сколько они живут и главное почему они возникают а возникать они могут в 4х основных случаях 1)некорректная просто работа с транзакциям (приложение не закрывает транзакции когда надо или открывает их когда не надо) 2)приложение внутри транзакций ходит к каким то внешним ресурсам с непредсказуемы и местами высоким временем ответа (и соответственно транзакция остается открытой пока приложение ждет ответа от этой внешней системы) 3)серьезная перегрузка backend по cpu и/или сети 4)проблемы сетевого уровня между backend и базой наиболее вероятно 2 или с меньшими шансами 1 хотя и остальные причины возможны. много idle in transaction никогда не является признаком проблем именно с базой. ps: что у pgbouncer с пулами видно в show pools. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 12:24 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
Maxim Boguk, Спасибо. Приложение пока не получается раскопать. idle in transaction висят довольно долго, больше минуты не бывает, но 30-50сек постоянно. Скорее всего первое, в сторонние системы приложение не ходит. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 14:53 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
Maxim Boguk, 3. CPU на вебе зачастую хорошо нагружен тоже ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 14:58 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
kliff Maxim Boguk, Спасибо. Приложение пока не получается раскопать. idle in transaction висят довольно долго, больше минуты не бывает, но 30-50сек постоянно. Скорее всего первое, в сторонние системы приложение не ходит. для вебпроекта даже 1s idle in transaction это много просто потому что максимум что вы выжмете из базы тогда это max_connection (=pool_size) / avg(время транзакции) транзакций в секунду ps: интересно как вы system time > user_time на backend добились то? pps: сочетание max_connections 3000 + work_mem = 2gb на базе меня пугает особенно на фоне памяти как у меня на ноутбуке. вы бы перемножили и поняли бы что для такой настройки вам нужен сервер с 6TB оперативной памяти чтобы не падать по ООМ в случайные моменты времени. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 15:05 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
kliff Maxim Boguk, 3. CPU на вебе зачастую хорошо нагружен тоже что говорит perf top? такое количество cpu system time - ненормально! ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 15:35 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
Maxim Boguk, авторps: интересно как вы system time > user_time на backend добились то? это вот да, интересный момент. Что касается памяти, то я до сих пор не могу сделать однозначных выводов по поводу необходимости ее наращивать. Вот график за полгода, пару раз было проблема с запросами, где зацикливалась рекурсия и память отъедало, но не в 0. Все остальной время 25-25 гигов свободно из 32. Разные эксперименты проводил, например делать shared_buffers больше 8Гб, получаю обратный эффект, производительность падает. Как выжать максимум из этих 32Гб пока не понятно. Хотелось бы конечно разобраться. Прочитал всю доку, посмотрел все обучающие курсы, но по мере углубления вопросов больше чем ответов. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 15:46 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
kliff, Говорят же вам. ворк-мем у вас неадекватен. Очень мало в каких случаях столько нужно задавать на уровне всего экземпляра. А ваш систем тайм может свидетельствовать о том, что ядра цп не успевают обрабатывать количество процессов, которые рожает приложение, и постоянно занимаются решедулингом(perf top). Я сталкивался с похожим. Снижайте default_pool_size для начала. Ну и статистику баунсера (show pools итд) в студию. желательно в графиках заббикса, конечно. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 15:50 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
mefman, не спорю, что неадекватен. Просто говорю ,что даже при такой настройке утечки памяти нет. Забикс для баунсера я пока не настраивал, не подскажете хорошую статью как его добавить в забикс? Я нашел инфу вроде, но пока не настраивал. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 16:54 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
mefman kliff Maxim Boguk, 3. CPU на вебе зачастую хорошо нагружен тоже что говорит perf top? такое количество cpu system time - ненормально! на вебе такая картина perf сейчас конечно не пиковые нагрузки. Баунсер пока пришлось выключить, потому что сервер не шевелится с ним. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 17:27 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
kliff сейчас конечно не пиковые нагрузки. Баунсер пока пришлось выключить, потому что сервер не шевелится с ним. как я уже писал - если у вас проблема с долгими транзакциями - надо pool_size повышать у pgbouncer до 100-200-300-500 пока у вас не будет waiting дальше разбираться откуда они почему и лечить после чего уменьшать пул до разумных значений разумная ситуция когда у вас в 90 - 99% времени waiting в pgbouncer нет. ps: поставьте мониторинг от окmeter на базу.. zabbix никогда не умел в postgresql/pgbouncer и не научится. а в окметре все видно out of box . -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 23:18 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
Maxim Boguk, Спасибо. окmeter поставил. Смотрю ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 09:30 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
kliff сейчас конечно не пиковые нагрузки. Баунсер пока пришлось выключить, потому что сервер не шевелится с ним. __d_lookup_rcu() определена в fs/dcache.c, т.е. это что-то связанное с работой кэша файловой системы на абстрактном уровне (VFS). Подсознательно кажется, что Ваш веб уперся в pgbouncer, плодит сессии и, возможно, сыпет килотонны логов. Но надо смотреть. kliff Решаемая проблема: большое количество коннектов на БД, около 500, и большое количество процессов 600-800, графики по нагрузке сервера БД очень неравномерные. Что именно Вас беспокоит в большом количестве коннектов? И, самое интересное, что Вас беспокоит в неравномерности графиков? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 12:59 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
Scott Tiger, bouncer не работает сейчас, все делается напрямую. Килотонн логов нет, вижу nginx пишет примерно 150мб в сутки и все. Неравномерность графика меня не то чтобы сильно беспокоит, оверхеды беспокоят и то, что сервер бывает тормозит или лежит. Количество коннектов - то что не один десяток раз читал на разных ресурсах и в роликах, что без пулера ПГ 9 хорошо работает с количеством коннектов не более 100, а у меня их немного больше 300-600. Пулер многие советовали не ставить, поскольку система больше olap, чем oltp. Как то так. На другом проекте, который я делал сам, отлично все работает с пулером, но там oltp в полный рост. А эта система досталась по наследству не в комплекте с ее разработчиком. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 13:35 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
Большое спасибо всем за помощь, буду тихонько дотягивать до перехода на новую ОС и новый Postgresql, а там уже все перепиливать. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 14:19 |
|
эксперимент с pgBouncer
|
|||
---|---|---|---|
#18+
kliff, большая часть засветившихся в выводе perf функций так или иначе связана с разрешением путей в файловой системе. Что-то Ваше приложение очень активно ищет на диске и, вероятно, находит. Возможно, это его внутренняя логика, возможно - связано с работой php-fpm. Тут нужно смотреть детально, потрассируйте аккуратно в период небольшой нагрузки. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2021, 14:37 |
|
|
start [/forum/topic.php?fid=53&fpage=17&tid=1994260]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
42ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 153ms |
0 / 0 |