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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Расселять БД на отдельные сервера не вариант ?

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

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

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

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

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

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

Ну хотяб на 4 сервака поделить.

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

А как же проблема 10к?

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

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

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

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

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

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

Нет такой проблемы.

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

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

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

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

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

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

Есть. Ты хоть раз видел постгрес вообще?

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

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

Он тебе железо родить должен?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Писец..........

64 GB но тут добавить не проблема

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1000 баз

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

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

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

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

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