|
|
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Из доки: http://wiki.postgresql.org/wiki/Number_Of_Database_Connections If you look at any graph of PostgreSQL performance with number of connections on the x axis and tps on the y access (with nothing else changing), you will see performance climb as connections rise until you hit saturation, and then you have a "knee" after which performance falls off. A lot of work has been done for version 9.2 to push that knee to the right and make the fall-off more gradual, Реквестируются графики из сабжа. Я, конечно понимаю, что неебически крутые перцы из комьюнити проделывали это 100500 миллионов раз, и им тесты написать - 10 мин. Но у меня ни тестовой среды, ни времени нету. Более того, изучение ведется в рамках написания доки к созданной системе без пула, с целью понять, где есть макс. производительность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 12:45:18 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Hawkmoon, пул нужен если большая часть установленных соединений (и соотв. запущенных pg процессов) висит в состоянии IDLE. смотрите pg_stat_activity. например установлено 80 соединений, в active состоянии 10 соединений, остальное IDLE, то пул поможет избавиться от IDLE, тем самым число коннектов к пг будет на минимуме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 13:08:31 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Hawkmoon, не понял, "прочотопек" если про затраты на поднятие соединений - и когда их не надо платить, настроив скажем баунсер -- то ответ : тогда, когда можно не платить (ползатели ходят под одним именем (группой имен), не хранят параметров сессии и/или т.п., из-за чего становится возможным пользоваться ранее поднятым "расшаренным" соединением) частный случай - ползатели разные, но у них недержание (своими силами) коннекта, -- всякий раз ломятся поднимать новый (процесс постгреса) -- тогда баунсер держит пул соединений за них. всегда, когда платить необходимо - ползатели строго разные, соединения и так держаться приложением в необходимом количестве, и, что хуже - всякое соединение отягощено своими собственными сессионными (отличать от транзакционных) переменными, которые не надо смешивать -- тогда пулинг ничего не даст, быть может за исключением некоторых специальных случаев. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 13:13:13 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Hawkmoon http://wiki.postgresql.org/wiki/Number_Of_Database_Connections If you look at any graph of PostgreSQL performance with number of connections on the x axis and tps on the y access (with nothing else changing), you will see performance climb as connections rise until you hit saturation, and then you have a "knee" after which performance falls off. A lot of work has been done for version 9.2 to push that knee to the right and make the fall-off more gradual, Реквестируются графики из сабжа. Перевожу для неграмотных: Если вы посмотрите на любой график производительности PostgreSQL, с количеством коннекшенов по оси х, и tps по оси y (где ничего более не меняется), вы увидите восхождение производительности, потом насыщение, а затем "knee", после которого производительность рушится. Много работы было проделано в версии 9.2 для того, чтобы отодвинуть это knee вправо и сделать падение более плавным. Отмечаю, что, разумеется, среднему программисту слово "график" не понять. В институты то ходили только поесть в дешевых столовках. Но тем не менее, повторяю вопрос: Реквестируются вышеупомянутые в доке графики ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 13:26:54 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
daevyHawkmoon, пул нужен если большая часть установленных соединений (и соотв. запущенных pg процессов) висит в состоянии IDLE. смотрите pg_stat_activity. например установлено 80 соединений, в active состоянии 10 соединений, остальное IDLE, то пул поможет избавиться от IDLE, тем самым число коннектов к пг будет на минимуме. Учитывая, что у меня до 1000 соединений, сигналы от "источников" поступают раз в секунду-пять секунд, а вставка делается не более чем за 0,1 секунду. Поэтому, чтобы расширяться дальше, можно внедрить пулинг (резервы вроде как есть - 0,9 секунд соединение провисает без дела). Пока что я просто ищу график из вышеупомянутой доки. Может, кто-то строил сам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 13:31:11 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Hawkmoon, на ум приходит такой вариант (но это так рассуждения, как бы я построил если бы мне поставили такую задачу). Свести в один график: 1) число коммитов (xact_commit) из pg_stat_database, считать дельту и делить на 60 если сбор ведется раз в минуту (но это мне кажется слишком грубая оценка) 2) count(*) from pg_stat_activity это число коннектов в заббиксе это делается на раз-два. риторический вопрос, но вот что делать дальше с этим графиком? увеличивать число коннекто дабы увидеть эту просадку или что?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 13:43:02 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Hawkmoon, я понял как его построить, судя из сабжа график статичный и не привязан по времени (про время там ничего же не говорится). его можно построить на тестовой системе с использованием pgbench c разным числом клиентов. по мере увеличения tps будет расти, но в какой-то момент при достижении некоего числа клиентов tps упадут вот и будет то самое 'knee'. но это вариант с синтетической нагрузкой, врядли его результаты можно будет проецировать на ваш продакшен. поразмыслил над предыдущим вариантом, чтобы учитывались еще и statement'ы можно использовать pg_stat_statements вместо pg_stat_database и считать sum(calls) тогда можно будет посчитать statements per second что как-то имхо более точнее будет отражать текущую нагрузку. ну данный график пригодится лишь в качестве отслеживания картины по текущему состоянию, спрогнозировать при каком кол-ве соединений наступит кирдык имхо невозможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 14:13:50 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
HawkmoonHawkmoonпропущено... Реквестируются графики из сабжа. Перевожу для неграмотных: Если вы посмотрите на любой график производительности PostgreSQL, с количеством коннекшенов по оси х, и tps по оси y (где ничего более не меняется), вы увидите восхождение производительности, потом насыщение, а затем "knee", после которого производительность рушится. Много работы было проделано в версии 9.2 для того, чтобы отодвинуть это knee вправо и сделать падение более плавным. Отмечаю, что, разумеется, среднему программисту слово "график" не понять. В институты то ходили только поесть в дешевых столовках. Но тем не менее, повторяю вопрос: Реквестируются вышеупомянутые в доке графики повторяйу: "прачотопег ?" графики - это то, что рисуйут. картинко 1. чем картинка отличается от текста -- это любопытный вопрос, обсуждаемый обычно в в ПТ в теме "кто знает очень смешную картинку" 2. и где ? /* никакой картинки ни тут ни там не увидел */ 3. про владение афтара русским делаем вывод из упорного применения дятлизма "реквестуются", там, где есть кондовые аналоги от отечественного 4. поскольку русским-могучем аффтар не владеет - есть сомнения в употреблении им и иноземного "рекв[а]ест" в оном 5. ну и т.п. PS я давно уже не читаю всё сплошь, даже кириллицей, а тем паче иноземщину[, а уж если вижу, что афтар жмётся и интригует как институтка, вместо прямой речи по существу - то вообще]. Резюме: сиречь, хочешь графиков - так и говори "ларису ивановну хочу". и неча тут выделываться PS про "любой график" - это очевидно умозрительно, т.ч. о чём тут думать ? Пока можете выиграть за счет распараллеливания (хоть что-то для процев там есть, есть что параллелить. дисковую параллелить бессмысленно.) -- имеет смысл параллелить. Как только задействовали все процы/ядра - выигрывать больше нечего, но при конкуренции всегда есть потери на её разрешение --> начинаем просаживаться за счёт роста этих затрат. я так понимаю - вас именно они и интересуют ? хотите сравнить с потерями пулера на пуллинг ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 14:53:12 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
qwwq, аффтары документации упомянули про график, описали его поведение, но не потрудились поднять свой зад, найти картинку и приложить его в вики. Так что тут не хотеть, а именно реквестировать надо. Авось моя такая тупая, что не может найти гуглом то, что и так должно быть. Более того, они явно грят, что поведение разное на разных версиях. Представляю, что было б, если б статьи по физике так писались. Заходишь прочитать, и видишь: "Мы тут построили установочку за стотыщ милльёнов, получили, что а меньше бэ. Кто не верит, пусть проверит. Лол" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 16:24:21 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Hawkmoonqwwq, аффтары документации упомянули про график, описали его поведение, но не потрудились поднять свой зад, найти картинку и приложить его в вики. Так что тут не хотеть, а именно реквестировать надо. Авось моя такая тупая, что не может найти гуглом то, что и так должно быть. Более того, они явно грят, что поведение разное на разных версиях. Представляю, что было б, если б статьи по физике так писались. Заходишь прочитать, и видишь: "Мы тут построили установочку за стотыщ милльёнов, получили, что а меньше бэ. Кто не верит, пусть проверит. Лол" так и я о том же правда из общих соображений всё многое упирается в вычислительную сложность запросов. для запросов разной сложности будем иметь разные выигрыши в "левой ветви" графика. от чего зависит правая часть - не очень ясно, в первом приближении только от поддержки конкурентности. (все эти ид сессий, транзакций, и т.п.) т.е. качественное поведение графика - таки да, таки такое, а количественне - "it depends" вот из-за этих "депендс" -- "его там и нет" такштааа - меряйте на своих типовых запросах - оно будет правильно. PPS я думаю, тут, в большинстве случаев, важнее, что не отдавая work_mem-ов на 1000, а отдав только 100 (благодаря пуллингу) вы можете безопасно отдать в shared больше памяти. Или выделить индивидуальному процессу побольше work_mem-а, если там вычисления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 17:37:29 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Вот поэтому я и хотел увидеть, то, что видели они, на картиночках. А не на словечках. Блин, что, так трудно картинку в вики вставить с минимальным описанием, а? Статью ж никто писать не просит. А теперь сиди, гадай... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 20:00:30 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
qwwqт.е. качественное поведение графика - таки да, таки такое, а количественне - "it depends" вот из-за этих "депендс" -- "его там и нет" Звучит как "все тела излучают по-разному, поэтому мы их спектр приводить не будем". Всегда в статейках пишутся: а. "депендентсы", при которых был проведен эксперимент, б. результаты в. выводы. Здесь же (гениальный подход!!!) (аффтар выпей йаду!!!) нету ни а, ни б. Зато есть "ввввыводы" на основе каких-то шаманских "танцев с бубнами". И таки да, я должен на основании этого просто поверить, что таки да, в 9.2 все гооооооооораздо лучшее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 20:04:46 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
lexa@nnn:~$ for clients in 1 3 10 30 100 300 1000; do pgbench -c $clients | grep -E 'number of clients:|tps ='; done number of clients: 1 tps = 110.234137 (including connections establishing) tps = 116.158859 (excluding connections establishing) number of clients: 3 tps = 100.738074 (including connections establishing) tps = 112.090031 (excluding connections establishing) number of clients: 10 tps = 102.667507 (including connections establishing) tps = 108.039664 (excluding connections establishing) number of clients: 30 tps = 93.946877 (including connections establishing) tps = 103.440143 (excluding connections establishing) number of clients: 100 tps = 91.543160 (including connections establishing) tps = 100.540860 (excluding connections establishing) number of clients: 300 tps = 61.113066 (including connections establishing) tps = 65.038401 (excluding connections establishing) number of clients: 1000 tps = 36.096999 (including connections establishing) tps = 37.359599 (excluding connections establishing) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 22:34:58 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat, Можно взглянуть на select version()? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 12:36:21 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
HawkmoonLeXa NalBat, Можно взглянуть на select version()? да в любой версии эта проблема... с увеличением номера она только отодвигается и становится менее жесткой... но даже -HEAD начинает после 64 паралельных запросов проседать заметно... 8.4 начинала проседать на 8 где то... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 13:08:22 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Maxim Bogukда в любой версии эта проблема... с увеличением номера она только отодвигается и становится менее жесткой... Весь тред как раз об этом - о поиске конкретики в плане "номера" и жесткости. Если чо, у меня продакшен на 8.4 сейчас крутится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 13:22:52 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Вот страничка из Т.Кайта, Оракл для профи, график, но опять без данных. Но здесь хотя бы форма приведена, и как раз та же, что и у описания pg. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 21:48:15 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
HawkmoonLeXa NalBat, Можно взглянуть на select version()? PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit слабенький домашний десктоп ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 22:42:52 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Hawkmoon, Нашёл-таки графики, которые Вам были нужны: http://rhaas.blogspot.ru/2012/04/did-i-say-32-cores-how-about-64.html и http://rhaas.blogspot.ru/2011/09/scalability-in-graphical-form-analyzed.html Получается, что если одновременных соединений меньше количества ядер, то пулер практически не нужен... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 04:03:22 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
UKY, О! Огромный плюс в ауру за это!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 09:53:36 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
UKYHawkmoon, Нашёл-таки графики, которые Вам были нужны: http://rhaas.blogspot.ru/2012/04/did-i-say-32-cores-how-about-64.html и http://rhaas.blogspot.ru/2011/09/scalability-in-graphical-form-analyzed.html Получается, что если одновременных соединений меньше количества ядер, то пулер практически не нужен... 1)На 8.4 все сильо менее радужно 2)в общем да если у вас 10-20-30 коннектов то проблемы обычно нет... 3)опять же если софт постоянно пересоединятся с базой вместо поддержки постоянного соединения - тогда всеравно нужен пулер так как соединение с PG штука крайне дорогая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 09:57:13 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, > соединение с PG штука крайне дорогая. А откуда следует это утверждение, это где-то описано в документации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 14:33:29 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Passer byMaxim Boguk, > соединение с PG штука крайне дорогая. А откуда следует это утверждение, это где-то описано в документации? оно известное... в доке где то скорее всего описано... на каждый новый конннект форкается норвый процесс postgres (что сама по себе очень недешевая операция) и инициализируется куча внутренних структур... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 15:24:33 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Соединение "дорогое" не только в PG. В Оракл тоже очень дорогое. Да и вообще для любой другой СУБД наверно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 16:00:07 |
|
||
|
Изучаю вопрос необходимости внедрения пула коннекшенов.
|
|||
|---|---|---|---|
|
#18+
Dim666Соединение "дорогое" не только в PG. В Оракл тоже очень дорогое. Да и вообще для любой другой СУБД наверно... Ну про Оракл тот же Кайт прямо говорит, что нефиг кучу коннекшенов держать - возьмите и гоняйте через одну штуку все запросы. Что у нас в pg на эту тему - я толком не разбиралси, но вот, к примеру, npgsql для .NET очень не любит, когда к его коннекшену с двух потоков два запроса идут... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2014, 16:30:08 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38603792&tid=1998756]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
188ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
74ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 518ms |

| 0 / 0 |
