LINUX.ORG.RU
ФорумAdmin

postgresql и 16000 соединений

 


0

1

Здравствуйте.

Есть postgresql сервер. На нем есть ~1000 баз.
Есть ~1000 клиентов. Каждый клиент работает только со своей базой. Так же каждый клиент может создавать до 16 подключений.

То есть получается ~16000 соединений до сервера. На таком количестве производительность postgresql около нулевая.

Подскажите, как можно захендлить такое? Или вовсе не реально?

Заранее благодарен.

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

Самый распространенный подход к решению этой проблемы - использование пула коннектов, либо на стороне приложения, либо как отдельного сервиса. Можно ли и как именно сделать это на стороне приложения - ну это тебе виднее, я же не знаю, как и на чем у тебя приложение сделано. Если отдельный сервис - смотри в сторону PgBouncer.

hippi90 ★★★★★ ()
Ответ на: комментарий от hippi90

От как раз самая проблема в том что приложений очень много.

А PgBouncer создает пул отдельно на каждую базу и тут он не применим.

karaien ★★ ()
Ответ на: комментарий от karaien

А других вариантов и нет. И даже если бы было, у тебя железо потянет если все юзеры одновременно начнут генерировать нагрузку?

Вообще, звучит как нонсенс, либо как работа для MySQL.

Так же каждый клиент может создавать до 16 подключений

Зачем? Это абсолютно бестолково и даже вредно в данной ситуации.

WitcherGeralt ★★ ()
Ответ на: комментарий от hippi90

ты чушь какую-то несешь. если он утверждает, что им нужно 16000 соединений, то значит им нужно именно 16000 соединений одновременно, со своей сессией. причем тут пулинг? pgbouncer тут не по теме.

новый процесс на каждое соединение, а это весьма расточительный подход ты можешь конкретно утверждать на каком железе это не будет работать, и начиная с какого железа уже будет? или просто балаболишь?

anonymous ()
Ответ на: комментарий от WitcherGeralt

Железо то потянет без проблем.

Вообще, звучит как нонсенс, либо как работа для MySQL.

К сожалению к постгресу уже намертво привязались.

Зачем? Это абсолютно бестолково и даже вредно в данной ситуации.

Знаю. Приложение написано очень криво и в некоторых моментах эму нужно именно 16 подключений. Переписать не вариант.

Сам слабо верю что что-то получится, но вдруг тут что-то да подскажут.

karaien ★★ ()
Последнее исправление: karaien (всего исправлений: 1)

звучит сомнительно, что этим неким клиентам нужно 16 подключений каждому.

кто такие «клиенты» вообще? ОП даже не способен сам понять, что он спрашивает.

клиенты в техническом смысле? - то тогда это «не 16 на одного», а 16 разных «клиентов». т.е. ОП не понимает, о чем говорит.

кроме того звучит сомнительно, что каждому клиенту нужна своя изолированная база, хотя это уже другой вопрос.

anonymous ()
Ответ на: комментарий от anonymous

Приложения написаны так что каждый воркер поток (их как раз 16) захватывает одно подключение к базе. При нормальном подходе там и 1 не всегда нужен, но что написано то уже написано и переписать не вариант.

И да, каждому приложению нужна своя база, поскольку структуры баз полностью разные.

karaien ★★ ()
Ответ на: комментарий от Deleted

Где же взять 1000 серверов, и даже страшно подумать сколько это будет стоить.

Сейчас планирую запасной вариант. Для каждой аппликации запускать отдельный постгрес в докере. Пока ничего лучше не придумал.

karaien ★★ ()
Ответ на: комментарий от karaien

структуры баз полностью разные.

У вас ит-стахановцы умудрились спроектировать 1000 разных БД со своей структурой каждая? Я такое, если честно, с трудом представляю. Тут одну-то базу месяцами проектируют и годами сопровождают. Такое ощущение, что ты либо чего-то не договариваешь, либо чего-то не понимаешь.

Про 5-6 разных баз я ещё поверю, и в этом случае вполне возможно их как-то обьединить…

Ты точно под структурой БД понимаешь то же, что принято?

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 3)

Ты сначала определись, в чём проблема, а потом уже решай. 16 тысяч соединений, как и 16 тысяч процессов это ерунда.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от karaien

Приложения написаны так что каждый воркер поток (их как раз 16) захватывает одно подключение к базе. При нормальном подходе там и 1 не всегда нужен, но что написано то уже написано и переписать не вариант.

Эти потоки одновременно посылают запросы или нет?
Если нет, то возможно pgbouncer + pool_mode=transaction может помочь.

Тогда соединений от pgbouncer до реальной базы может быть намного меньше, чем соединений от клиентов до pgbouncer.

AnDoR ★★★★★ ()
Ответ на: комментарий от hobbit

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

Мне самому это не нравится и это в корне не правильно, но переписать все нет возможности (проект просто громаден и очень сложен).

karaien ★★ ()
Ответ на: комментарий от AnDoR

Все равно получается не менее 500-700 соединений, при таком количестве в тестах производительность постгреса падает до 4 раз.

karaien ★★ ()
Ответ на: комментарий от Legioner

Для постгреса уже 100 соединений проблема, даже если они ничего не делают.

karaien ★★ ()
Ответ на: комментарий от karaien

Для каждой аппликации запускать отдельный постгрес в докере

Лучше от этого не станет, и по ресурсам просядет и файловая подсистема у тебя всё равно одна.

Так может всё же попробовать поднять PgBouncer, и задать пул из одного единственного соединения? Это уже 1 тысяча соединений к бд вместо 16.

WitcherGeralt ★★ ()
Ответ на: комментарий от karaien

в тестах производительность постгреса падает до 4 раз

А на какую магию ты надеешься? Тут следует испытывать восторг от того, что это в принципе хоть как-то работает при таких раскладах. Ты ничего не можешь поделать, кроме как дать по щам быдлоразрабам, которые это наваяли.

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 1)
Ответ на: комментарий от WitcherGeralt

ктоме как дать по щам быдлоразрабам, которые это наваяли.

Я бы дал по щам админам, которые тысячу приложений натравливают на один сервер БД. Даже если бы каждое приложение открывало одно-единственное соединение, это уже тысяча коннектов на ровном месте. А 16 коннектов на приложение, это не так много, если они там в пуле крутятся.

hippi90 ★★★★★ ()
Ответ на: комментарий от hippi90

Если честно, то проблема в 1000-че клиентов и всего одном сервере. В постгресе же есть какое-никакое горизонтальное масштабирование. А вот кто виноват, что оно не используется и сервак всего один? Архитектор.

dsxl ()
Ответ на: удаленный комментарий

Очень жду ваш вариант и желательно аргументацию почему «запускать отдельный постгрес в докере» == «Эпический идиот».

karaien ★★ ()
Ответ на: комментарий от karaien

Какую проблему это решит? Станет меньше соединений? Наоборот, будет лишний оверхед. Докер он не про производительность, а про разворачивание.

goingUp ★★★★★ ()
Ответ на: комментарий от karaien

Приложения написаны так что каждый воркер поток (их как раз 16) захватывает одно подключение к базе.

Значит разработчик решил не сериализовывать доступ к базе на своей стороне. Это нормально, кстати говоря. И удобно. Этот вовсе не признак кривого приложения, наоборот - реляционные БД это умеют хорошо. Другое дело, что может быть хотя бы часть доступа там можно было бы сериализовать и делать через одно подключение.

и переписать не вариант

Что значит «не вариант»? В смысле? Если нужно переписывать - значит нужно. И сколько за это денег и времени попросят - столько и будут платить.

anonymous ()
Ответ на: комментарий от goingUp

Это решит проблему того что к одному инстансу постгреса будет только 16 соединений.

То есть 1000 инстансов постгреса по 16 соединений каждый будут работать быстрее чем 1 инстанс с даже 1000 соединений.

karaien ★★ ()
Ответ на: комментарий от anonymous

Что значит «не вариант»? В смысле? Если нужно переписывать - значит нужно. И сколько за это денег и времени попросят - столько и будут платить.

Ох как бы я хотел что б в реальном мире это так и было...

karaien ★★ ()
Последнее исправление: karaien (всего исправлений: 1)
Ответ на: комментарий от karaien

Ох как бы я хотел что б в реальном мире это так и было… Именно в реальном мире будут переписывать и платить сколько скажут, если это действительно нужно. Если не хотят, сворачивают этот бизнес и занимаются другим. Не хотят сворачиваться? Значит будут переписывать.

Вот в маняфантазиях, там да - там можно говорить «переписывать не вариант».

anonymous ()
Ответ на: комментарий от karaien

Ох как бы я хотел что б в реальном мире это так и было…

Именно в реальном мире будут переписывать и платить сколько скажут, если это действительно нужно. Если не хотят, сворачивают этот бизнес и занимаются другим. Не хотят сворачиваться? Значит будут переписывать.

Вот в маняфантазиях, там да - там можно говорить «переписывать не вариант».

anonymous ()

Интересная задача. Скажите если не секрет, какая конфигурация сервера вами сейчас планируется для покупки под эту задачу? Сколько процессоров/ядер, сколько памяти рассчитываете? Что за диски, контроллер?

anonymous ()
Ответ на: комментарий от karaien

Любые базы данных, в том числе постгрес нормально работают на машинах с 1 и более ТB памяти. У оракла есть инсталляции, где адресуется больше ТБ, у постгреса, уверен, тоже. Кроме того, есть нужно заставить постгрес использовать какие-то совсем не вероятные объмы памяти (сколько это сегодня? 20ТБ?), то в России есть консалтеры (ключевые разработчики постгреса) они просто доделают постгрес для вас или для всех. Известно, что есть инсталляции постгреса где данных на дисках около 100 ТБ. Но я думаю, это совсем фигня, скорее всего есть и больше. В современных чипах по 24 процессора, то есть 48 процессоров или 96 лже-процессоров на двусокетной машине. Я не понимаю, в чем у вас проблема в оригинальном посте.

Что касается 16000 подключений: утилизировать чуть ли не все ресурсы можно одним единственным запросом, отправленным через одно единственное подключение. Какие выборки выше приложение делает, как и сколько данных обновляет, какие у вас там хп - никто знает и наперед ничего не скажет.

anonymous ()
Ответ на: комментарий от AnDoR

Вот еще один не понимающий, что такое базы данных вообще. Пгбаунсер тут вообще не применим. Это глупость.

anonymous ()
Ответ на: комментарий от karaien

1000 инстансов постгреса по 16 соединений каждый будут работать быстрее чем 1 инстанс с даже 1000 соединений.

На одном и том же сервере? Как то сомнительно. За счет чего? Я не знаю внутренности постгреса, но чего-то у меня есть сомнения, что у постгреса нету индексов на базы/пользователей/коннекты, и даже если нету, 1000 элементов это не сильно много. А так наоборот, вангую, что отдельные инсталляции будут расходовать сильно больше памяти. Вам нужно определить, что именно тормозит на вашем сервере.

goingUp ★★★★★ ()
Ответ на: комментарий от goingUp

Как то сомнительно. За счет чего?

Так они же будут в докере работать

anonymous ()
Ответ на: комментарий от hippi90

это уже тысяча коннектов
тысячу приложений натравливают на один сервер
Я бы дал по щам админам

о, сисадмин $10-вых впсок не одобряет

anonymous ()

Накати Кокроч кластером. Там протокол Постгреса из коробки. Вот и всё. Распределяй и властвуй.

anonymous ()
Ответ на: комментарий от karaien

в шаред_буфферс как можно больше памяти отдай.

пейдж кеш, на который постгрес надеется, вымывается ппц.

drsm ★★ ()
Ответ на: комментарий от karaien

2x Intel Xeon E5-2620v3 64 GB но тут добавить не проблема. ssd 4x480Gb raid10, какие-то intel, точно не помню.

Норм тема. Я чуть чаем не поперхнулся. У меня подобная тачка средненько ~200 «клиентов» держит, средней нагруженности )))

Наверное если буфера выкрутить в минимум как-то оно будет функционировать..

vasily_pupkin ★★★★★ ()

16000 постоянно открытых коннектов?

anonymous ()

1600 – это тебе Аероспайк нужен.

anonymous ()

Я бы для начала провёл простой тест. Замерить, как оно работает на 1024 коннектов. Запустить два постгреса с 512 подключений к каждому, замерить. Если показатели стали лучше, продолжить дробить, пока не станет хорошо.

Это не обязательно запускать в докере, просто несколько инстансов рядом.

ЗЫ ещё один неосилятор постгреса и «вообще как работают бд».

filosofia ()
Ответ на: комментарий от Deleted

Добавь до размера ssd. Пущай все базы кеширует

Да ничего они добавлять не будут. Это днище ваннаби-бизнесмены с админом-полудурком. Поправить приложение - сложно, долго, «нет» денег, не вариант. Найти хотя бы на время приличный сервер для тестов и запрограммировать эмуляцию нагрузки - сложно, долго, «нет» денег, не вариант. Нанять нормального специалиста - сложно, долго, «нет» денег, не вариант. Они потратят какие-нибудь совсем смешные деньги вроде $1k на пару недель никак не относящихся к делу глупостей («а давай pg_bourncer попробуем», «а давай docker попробуем», и т.д.) и забудут об этой затее. Нет у них там никакой системы, просто гора мусора которой никто не пользуется. Не надо их воспринимать серьезно.

anonymous ()
Ответ на: комментарий от karaien

1000 баз

структуры баз полностью разные

Какую только дичь не придумают! И ведь не в один же день это запилили, как же оно работало когда было 999 баз?

no-such-file ★★★★★ ()

производительность postgresql около нулевая

Не увидел совета посмотреть почему. vmstat хотя бы.

DonkeyHot ★★★★★ ()
Ответ на: комментарий от DonkeyHot

По мне так всё это глупости. Он вроде бы где-то сказал «производительность падает в четыре раза». Что значит? Есть конкретная выборка которая стала работать ровно в 4 дольше? ХП? Конкретный апдейт на конкретной таблице? Конкретные индексы стали в 4 раза дольше? Установка нового подключения? Вакуум? Запрос упирающийся в CPU замедлился в 4 раза? Запрос который раньше сортировал в памяти вдруг замедлился в 4 раза? Это бессмысленно обсуждать, какой vmstat, это глупости. Эта информация ничего не даст. Я уже выше написал, это проблема которой нет, в системе которая никому не нужна, на решение которой нет денег и нет ни одного специалиста.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.