Компания Cloudflare опубликовала исходные тексты собственной редакции прокси-сервера PgBouncer, применяемого для поддержания пула открытых соединений к СУБД PostgreSQL. PgBouncer позволяет наладить обращение приложений к PostgreSQL через уже установленные соединения для исключения постоянного выполнения ресурсоёмких повторяющихся операций открытия и закрытия соединений и снижения числа активных соединений к PostgreSQL...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57683
Перевожу на человеческий - в хайлоаде с постгре без костылей не получится.
пул коннектов везде актуален, но с другой стороны слишком жирновато персональные коннекты
Хайлоад бывает без костылей?
В PostgresPro есть встроенный пулер. Это тоже считается костылями?
>PostgresPro есть встроенный пулерденьги платить и вендорлочиться? вы с ума сошли
хайлоад без денег, вы с ума сошли?
>хайлоад без денег, вы с ума сошли?ты за спринг, кафку, хадуп, спарк итд деньги платишь, фантазёр? )
Очевидно, что деньги совсем не ща соыт платятся, а ща то, чтобы он работал. Иными словами, за саппорт, который знает как его тюнить, чтобы мне не нужно было своё время на incidental complexity.
у тебя хайлоуд и ты не купил подписку на Spring и Kafka поддержку? ))
А кто тебе бесплатно даст? Microsoft, Oracle, IBM?
Да
>в хайлоаде с постгре без костылей не получитсяв хайлоаде постгреса нет. может у свечек бухгалтерия в 1Се, вот и всё применение )
У 1С есть сервер к которому обращаются все клиенты, а он уже к postgres. Нормальные приложения в хайлоаде имеют свой пулер.
Нормальным приложениям ненужен внешний пулер. Их пишут так чтобы они не спамили конекшонами на каждый чих.Какой-нибудь дотнетовский линкскуель и похожая лажа в хайлоаде это безумие.
> Нормальным приложениям ненужен внешний пулер. Их пишут так чтобы они не спамили
> конекшонами на каждый чих.
> Какой-нибудь дотнетовский линкскуель и похожая лажа в хайлоаде это безумие.И как ты без промежуточного сервера будешь разруливать хотя бы сотню клиентов которые на каждый чих генерят кучу запросов. А фоновые задачи? Сейчас практически любое более менее серьёзное приложение хоть 1С хоть интернет магазин это трехзвенка клиент-сервер приложения-сервер БД.
Речь же о хайлоаде шла, а не этом вот всём безобразии.Нормально писать клиентов нормально всё будет.
Сотня клиентов это вообще не о чём.
По конекшону на клиента и проблема пулинга конекшонов решена.Чтобы не спамили кучей запросов есть инженер баз данных(или как-то так), который нормальные запросы и сценарии спроектирует. И к нему программист который это разумно закодит.
Хайлоад, это не то же самое что высокая нагрузка. Можно написать отвратительное приложение которое будет грузить сервер, это не будет хайлоадом.
> Сотня клиентов это вообще не о чём.
> По конекшону на клиента и проблема пулинга конекшонов решена.Напомню тебе один момент, у того же ms sql каждый конекшен стоит отдельную денюжку
> Чтобы не спамили кучей запросов есть инженер баз данных(или как-то так), который
> нормальные запросы и сценарии спроектирует. И к нему программист который это
> разумно закодит.Вот тебе сценарий. Табличка из нескольких сотен тысяч строчек. Например список документов. Списочек этот формируется запросом в котором есть левые соединения. Пользователем курсорчиком промотал табличку вниз, оппа запросик выполнился и вернул ещё пару сотен строчек. Пользователь увидел нужный ему документик, и щёлкнул чтобы его открыть. И полетели запросики. Во-первых, может ли вообще этот пользователь открыть вот этот конкретно документ, а может именно этому пользователю разрешено только посмотреть, а может разрешено посмотреть и добавить строчку в определённой табличной части, и таких а может может быть много. Потом если надо что-то добавить в документ тут тоже нужны запросы и скорее всего не один. А потом начинается самое интересное запись в документ. Тут может быть несколько десятков запросов, при проверке перед записью и во время записи. И так регулярно и не один пользователь а десятки или сотни. А ведь в этом время ещё выполняется не один десяток фоновых сценариев, запись новых цен если они считаются автоматом, актуализация итогов, всякие синхронизации с другими базами и т.д. все это тоже десятки запросов и на чтение и на запись.
> Хайлоад, это не то же самое что высокая нагрузка. Можно написать отвратительное
> приложение которое будет грузить сервер, это не будет хайлоадом.А можно на диванчике сидеть и с умными видом рассуждать как правильно писать приложения. Ведь ты же все бы сделал как надо, просто не хочешь.
Да какое отношение число запросов к коннекшен пудингу вообще имеет.>А можно на диванчике сидеть и с умными видом рассуждать как правильно писать приложения.
Диванчика нет, сижу на кровате в съемной квартире так как из за войны я теперь необомж.
На счёт вида не уверен, был бы я в такой заднице если я такой умный?
>Ведь ты же все бы сделал как надо, просто не хочешь.Сделаю как надо если мне за это заплатят. Понятное дело ради спора на опеннете я не кинусь кодить.
И вы наверное тоже не станете ваш пример оформлять в реальную базу, писать сценарии и тесты для этого гипотетического специального соревнования.Я в курсе примерно современных реалий кровавого ентерпрайза, они мне просто не по душе.
Считаю что можно и нужно достигать большего меньшими усилиями.
>Диванчика нет, сижу на кровате в съемной квартире так как из за войны я теперь необомж.Сочувствую.
>На счёт вида не уверен, был бы я в такой заднице если я такой умный?
Тут многое от удачи зависит. Знакомый свинтил с семьей из Днепропетровска пока не загребли на фронт прямо в Россию. Выехал в Польшу, недельку глянул на ту жопу, и через Белоруссию не останавливаясь прямо сюда.
> И вы наверное тоже не станете ваш пример оформлять в реальную базу,
> писать сценарии и тесты для этого гипотетического специального соревнования.Так это и есть типичный пример практически из любой конфигурации 1С.
> Я в курсе примерно современных реалий кровавого ентерпрайза, они мне просто не
> по душе.
> Считаю что можно и нужно достигать большего меньшими усилиями.Любимые зумерами хранилища ключ-значение прокатят только чтобы состояние кнопочек для фронта хранить. А в кровавом ентерпрайзе без кучи здоровых и тяжелых запросов с кучей соединений десятков таблиц, временных таблиц, менеджеров временных таблиц, пакетов запросов и т.д. не обойтись. И всем этим должен кто-то рулить.
> Сочувствую.Спасибо. Словами тяжело описать что мы пережили.
> Так это и есть типичный пример практически из любой конфигурации 1С.
С 1С не знаком от слова совсем.
> Любимые зумерами хранилища ключ-значение прокатят только чтобы состояние кнопочек для
> фронта хранить. А в кровавом ентерпрайзе без кучи здоровых и тяжелых
> запросов с кучей соединений десятков таблиц, временных таблиц, менеджеров временных таблиц,
> пакетов запросов и т.д. не обойтись. И всем этим должен кто-то
> рулить.Вероятно что так.
> Спасибо. Словами тяжело описать что мы пережили.Я немного в курсе, если можно так сказать. У меня есть пара знакомых. Одна в Николаеве, похоже я для неё теперь враг, хотя были чуть ли не лучшими друзьями. Вторая в Кривом Роге, эта тоже вся на эмоциях, но с ней мы вроде решили что тут от нас лично ничего не зависит, и нет смысла ругаться.
Мы бежали под обстрелами. Чудом разминулись со снарядом на улице.
Сами по себе волны взрывов от которых сотрясается дом это неописуемый ужас.
> Мы бежали под обстрелами. Чудом разминулись со снарядом на улице.
> Сами по себе волны взрывов от которых сотрясается дом это неописуемый ужас.Реалии современных конфликтов, кто-то бежит от обстрелов буквально под взрывами, а кто-то в соседнем городе жалуется на мелкие бытовые неприятности, хотя воздушные тревоги в Кривом Роге объявляют по 10 раз на дню, она мне присылала скрин из телеги.
Когда приехали в другой город были удивлены как люди реагируют на тревогу. Искренне пугаются, спускаются в подвалы.
Сейчас вроде привыкли уже и не так боятся. В Харькове же тревоги вообще никакой не было в начале войны, система не работала.
Да, людям конечно срывает крышу от этого всего.
Оставаться человеком в таких условиях очень сложно.
Не говоря уже о законах запрещающих сомнения и размышления.
И чем дольше затягивается конфлик тем больше будет ненависти и жестокости.
> Считаю что можно и нужно достигать большего меньшими усилиями.Так вот отдельный общий, один на всех, универсальный пулинг соединений и есть меньшие усилия. Не надо в каждом приложении или стеке с собой его уникальный пул-велосипед тягать. Вместо тебя кто-то напрягся, сделал, а ты в разных приложениях единообразно используешь как-будто соединения у тебя выделенные и открытие/закрытие ничего тебе не стоят - лафа.
Под усилиями подразумевалась сложность системы, нагрев вселенной, а не усилия отдельных работников галеры.
Сложность системы уменьшается. Разница в нагреве вселенной от выбранного варианта пулинга мизерная, почти нулевая, по сравнению с работой, которая совершается за кулисами БД, тратится на перегонку данных в обоих направлениях и на обработку этих данных на клиентской стороне. Нечего пытаться спасать сучкИ и крохотные веточки, когда вокруг тебя гектары леса валятся - сам лес спасай: оптимизируй архитектуру приложений/структуры данных, обычно там основные проблемы.
Можно не рубить лес гектарами, о этом речь.
Можно. Если у тебя весь проект это "Hello, world" или не сложнее вызова оракловского "select * from dual".
А мужики то не знают.
При насильственном внедрении импортозамещения в одной отдельно взятой организации - не поверишь, но таки Postgres добровольно-принудительно заменяет продукцию западных фирм, которые обычно ассоциируются с HighLoad. Да, с матами и грустью в глазах сопровождающих, но заменяет. И даже всё работает. Не так удобно как раньше, но работает. И таки да, в организации реальный HighLoad.Полагаю, не только в этой самой организации такое происходит :)
Вполне себе посгря может обеспечивать хайлоад. Вопрос в том как её применять.
А что, есть другие варианты?
Писать нормально чтобы ненужен был внешний пулер.
Классный рецепт, три звезды мишлен. Ты как будешь без внешнего пулера, если у тебя допустим, Чёрная пятница, народу привалило так, что 100+К rps это ещё штатная нагрузка. И кластер из кучи нод бэка, который пуляет в кластер БД с асинхронным реплицированием по CQRS подходу. Там нужно по внешнему пулеру на каждую БД ноду + клиентский пул на каждой ноде бэка.
Вам не нужен пулер для бекэнда если ваш бекэнд сам контролирует соединения с БД и поддерживает несколько параллельных соединений. Для бд оптимальным будет по соединению на одно ядро ЦП.Не знаю что с постгри но с мускулом это оптимальная стратегия.
Если ваш бекэнд спамит соединения на каждый чих его нужно сжечь.
Сначала нужно учесть, что постгря в отличие от мускуля не на потоках, а на процессах. На каждое соединение спавнится отдельный подпроцесс, который очень жирный и очень дорогой по startup time. Поэтому для постгри idle соединения беда бедовая и нужен мультиплексор. Если у тебя кластер из узлов бэка, в конфиге каждого узла нужно ограничить соединения в БД пуле до доли от общего количества, иначе какой-то узел "перетянет одеяло на себя". А учитывая что щас любой ынтерпрайз - это контейнеры и кубер (и его дистрибутивы, типа OpenShift), то их модель работы плохо ложится на клиентский пулинг (кубер в любой момент может потушить контейнеры в облаке, исходя из текущей нагрузки), то верхние границы оставшихся в живых клиентских пулов перестают соответствовать текущему конфигу max_connections сервера PG (а max_connections никогда не будет большим, иначе база сожрет весь хип). Поэтому де-факто уже давно стандартный рецепт воткнуть pgBouncer как внешний прокси и не придумывать себе задачи на ровном месте. Работает - работает. К производительности решения вопросы есть? Нет. Если же у вас монолит или кластер какой-нибудь на какой-нибудь технологии из прошлого, по типу JavaEE application server, то действительно внешний пулер не сдался, всё можно засунуть в клиентский. Справедливости ради, если какой-нибудь бизнес заказал вам разработку сервиса в интернетах (типа магаза), то у него должны ОЧЕНЬ хорошо идти дела, чтобы ему начало не хватать монолита PHP/Python + MySQL. Я в начале своего айтишного пути работал в одной крупной российской торговой компании с федеральным охватом. Они сидели на Битриксе 15(!) лет и начали переползать на Golang и VK-шные и Яндексовские облака, только когда открыли больше 150 магазинов по стране, а количество сотрудников перевалило за 3000. Сделаю еще раз акцент на том, что даже такое днище как Битрикс до вышеобозначенных цифр держал нагрузку.
Спасибо, интересно.
> Для бд оптимальным будет по соединению на одно ядро ЦП.А мне кажется, что это крайне неоптимально и мало, если у тебя много клиентов и одновременных запросов от них. Каждое соединение много времени проводит в ожидании ввода/вывода, в ожидании возврата из системных вызовов или возврате результата из движка БД. Т.е. у тебя сейчас активно просятся 400 клиентов в работу, а ты им там всего 4-8-16 соединений выдал. На каждое получение соединения, ожидая его освобождение, выстроилась очередь, а оно (соединение) занято - вальяжно развалившись и простаивая (ты же внутри не используешь корутины или другие зеленые или настоящие треды?) ожидает, ковыряясь в носу, возвращения управления из сискола или результат выборки по 10 таблицам. ОС конечно переключится на процесс другого соединения, но их всего 4 и остальные так же ждут данных или возврата из сискола. Про мгновенный реактивный, с затратами 0 времени, ответ на запрос из БД, пожалуйста, не надо. В реальной жизни это самое медленное во всей в этой цепочке.
Очередь само собой асинхронно обрабатывать. Запросов очередь на клиенте(допустим каком-то бекенде)
Я не о пулинге соединений говорил.
А о том что можно организовать на клиенте очередь запросов которая будет выгрибаться неким небольшим числом постоянных соединений с БД.А база данных не станет быстрее отвечать на запросы от того что к ней куча соединений идёт, на оборот произойдет.
Конечно оптимальное число соединений определяется опытным путем и зависит от характера запросов.
Это для приложений, у которых нормально не реализован пул подключений на клиентской стороне? Или дополнительная прокладка в виде промежуточного пула?
Если у тебя весь бэк в кубере и скейлинг под нагрузкой в десяток подов,то без баунсера никуда потому что это глобальный пул для всех, которым проще управлять. А клиентские пулеры только в рамках одного инстанса работают.
А теперь русскими словами...
Скейлинг->масштабирование, не благодари. Остальное, вроде, по-русски.
Масштабирование(рус)/scaling(eng). А что такое "скейлинг" - понятно только из твоего разъяснения.
Поды - это что? Гуглится pod - как электронная сигарета. Или из вики: Под (степное блюдце) — пологое замкнутое бессточное понижение рельефа. Ты их имел ввиду? Тогда нихрена в твоем посте не понятно.
Поэтому и попросили тебя перевести на русский с х.з. какого слэнга.
Вообще, это нормально использовать привычную терминологию без перевода. Никто же не говорит брандмаузер в быту, все говорят файрвол. А насчёт второго, чувак же сказал, что это из кубера терминология. У меня первая ссылка в гугле на кубернетсы, и это не персонифицированная выдача -- никогда с этим не работал. Но обычно такое понимается из контекста.
Ну, вот выше человек не просто так ведь попросил перевести.
Я бы тоже, будь не в теме - не понял бы. Несложно ведь сразу написать, чтобы всем было понятно без гугления.
Вы просто гуманитарии
Не угадал. Ванговать точно не ваше.
> Несложно ведь сразу написать, чтобы всем было понятно без гугления.Зачем? Нет, вот ты объясни: зачем? Если человек не в теме, то зачем ему понимать что говорят по этой теме? Но нет, кому-то оскорбительно понимать, что он не в теме, он чувствует себя тупым как пробка, и вот он уже лезет с уем наперевес на баррикады, доказывать всем окружающим что они тупые, а он как раз умный. Из-за того, что он не понял то, что ему нет никакой нужды понимать.
> Поды - это что? Гуглится pod - как электронная сигаретаГугл показывает персонализированную выдачу. Занимался бы ты системным администрированием — нагуглилось бы кое-что иное. Так что сиди кури, эникей.
Запросы в основном о "системном администрировании" и около того, и гугл вот такое выдал(правда на домашнем пк, но не суть - там тоже в основном технические сайты открываются). Выходит, не всегда срабатывает "персонализированная выдача".
>>Так что сиди кури?
>> эникей.Если не можете с точно определить уровень знаний человека в какой либо области, лучше этого не делать.
Чел, sorry за прямоту.
Если ты IT-специалист - погугли Kubernetes. В соответсвующих статьях всё будет описано в лучшем виде )
Если не IT-шник - объяснить, что комментатор выше сказал - задача крайне нетривиальная, примерно на 1/2 страницы А4 убористым почерком ))
Если ты не можешь в пару строк нормальным языком это объяснить, ты сам ничего не понимаешь.
Ну давай, объясни «нормальным языком» в «пару строк», чем занимается DevOps. Только так, чтобы твоя бабушка поняла, иначе ты сам ничего не понимаешь.
Тем же, чем одинэсники, только с докером.
Хернёй он занимается.
Чья бы корова мычала. Если ты не понимаешь каждое второе слово, то это ты совершенно не в теме и ничего не понимаешь. Не надо тут стрелки переводить.
Я отлично понимаю, достаточно для того, чтобы понять, что этот речехрюк нужен исключительно для идентификации себя как специалиста в этой области. Реальной смысловой нагрузки там нет, и это маскируется иностранными словами.
> Я отлично понимаюЭто я отлично понимаю, что ты не являешься специалистом ни в одной области, не овладел ни одним из профессиональных сленгов, и поэтому не понимаешь удобства и необходимости этих самых сленгов.
> Реальной смысловой нагрузки там нет, и это маскируется иностранными словами.
Конечно же если ты заявишь что так, то оно сразу так и станет, да? Веришь в то, что слова магическим образом могут менять реальность? В Деда Мороза тоже веришь?
> Поэтому и попросили тебя перевести на русский с х.з. какого слэнга.А не пойти ли бы вам? Если ты не знаешь профессионального сленга, то что ты лезешь в профессию? Если тебе интересно иди почитай туториалов по kubernetes, если не интересно и ты за русский язык воюешь то иди на какой-нибудь литературный форум. Там тебя примут.
Мы обсуждаем пулер, а не подокубернетиз. Поэтому пример должен быть болле понятным, в контексте пгбаунсера, а не микросервисного пода.
> Мы обсуждаем пулер, а не подокубернетиз.И как раз этот пулер в системе на кубере оказывается полезным. И что теперь? Тот кто хочет это сказать должен излагать тебе азы кубернета, туториал тут написать, книжку целую, чтобы ты потом смог понять зачем куберу баунсер?
Не должен. Это интернет, детка, тут никто никому ничего не должен. Я знаю, что это доходит туго, мне лично потребовалось лет десять, чтобы понять. Но ты напрягись, может ты покажешь себя умнее меня, может до тебя дойдёт быстрее?
>>А не пойти ли бы вам?Я понимаю, что интернет позволяет, но все же не стоит грубить.
Тема про пулер для PostgreSQL, а не про контейнеры. И людям, не знакомым с слэнгом kubernetes-админов(не все ведь в ИТ оркестрацией занимаются, верно?) может быть непонятен твой комментарий, при том, что то же самое можно написать понятно. О чем я и написал.
> Я понимаю, что интернет позволяет, но все же не стоит грубить.У тебя может и не стоит, у меня стоит.
> И людям, не знакомым с слэнгом kubernetes-админов(не все ведь в ИТ оркестрацией занимаются, верно?) может быть непонятен твой комментарий, при том, что то же самое можно написать понятно.
Это проблемы этих людей, и им следует держать их при себе.
Идейно крепкий речекряк
Ехали микросервисы через микросервисы.
Видят микросервисы транзакшионал датабейс сервер в микросервисы.
Сунили микросервисы микросервисы в микросервисы.
Скалинг скалинг скалинг скалинг.
Встроенный в приложение пул подключений помогает, но в случае нескольких приложений, работающих с общей БД, общий пулер перед СУБД, работающий в режиме transaction по-прежнему позволяет достичь дополнительной экономии подключений.
в режиме transaction у pgBouncer есть громаднейший недостаток в виде отсутствия совместимости prepared statements с этим режимом. В зависимости от требований бизнеса по SLA таймингам на REST, это может быть критично.
Если у бизнеса из-за разницы prepared vs plain падает весь прод то это явно не в баунсере проблема
Речь о штатных ситуациях, а не о падениях. Бизнес хочет например выделяться качеством обслуживания и с самого верха спускаются верхние пороги метрик, что и за сколько должно отрабатывать. Например, REST от запроса до ответа должен отрабатывать не более 2 секунд по 90 перцентилю нагрузки за последний месяц. В таких условиях ограничения, накладываемые инфраструктурными инструментами, тоже начинают играть свою роль.
> не более 2 секундЗа 2 секунды можно выполнить 20 000 plain запросов, без prepare.
Запрос запросу рознь. У нас на проекте была задача в 2 секунды впихнуть построение BI аналитики на джойнах по, кажется, 17 таблицам с оконными функциями, и дерганьем инфы из json столбцов, в каждой из которых было от 10 до 30 млн записей. Сам запрос был на несколько сотен строк. Вынесение его в prepared давало примерно 10% ускорение, так как этот отчёт в течение дня в департаменте бизнес-аналитиков дергался постоянно. Так что терять такой прирост на баунсере тупо жалко в сложных случаях.
Odyssey 1.3 умеет готовить statement, яндекс пилит https://github.com/yandex/odyssey/releases
--
меня больше не нравится изменение параметров сессии, которое влияет на всех, какой-нибудь set transaction read only. И бегут жаловаться.
Открываю issue, чет одна из первых бажин сверху, что prepared statement не фурычат.
> в опубликованном форке реализована возможность ограничения размера пула соединений для каждого пользователяв ванильном баунсере изначально все пулы ограничены по пользователям
> Предложенные в форке изменения нацелены на более строгую изоляцию ресурсов на уровне отдельных БД (нагрузка на CPU, потребление памяти и интенсивность ввода/вывода) и обеспечение ограничения числа соединений в привязке к пользователю и пулу соединений. Например, в опубликованном форке реализована возможность ограничения размера пула соединений для каждого пользователя, корректно работающая в конфигурациях с аутентификацией по имени хоста (HBA, host-based authentication)На самом деле там просто починили обработку пользователей из блока [users] в ini файле, ни про какие CPU или hba там речи нет.