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

да там походу воркеры в work_mem всю память выжирают, вот и «тормозит», лол.

какраз 4M * 16k = 64G

всё это глупости

IMHO мало бросаться говнами, нужно делать это так, чтобы человечество двигать в «нужную» сторону.

work_mem всю память выжирают

Если так - вот же сразу очевидно как чинить, и на форум не ходи.

Очевидно тут только то, что если менять приложение нельзя, придется мультиплексить транзакции.

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

но это все гадания от делать нехер, так я на 100% согласен с аноном.

снизить число воркеров

Раве уже доказано, что проблема в количестве воркеров? Поверхностный гуглёж говорит, что в этом месте линукс O(1)тлично масштабируемый(сам не проверял). Т.ч. может и не нужно ничего снижать.

Ты что, каждый процесс - это же целый процесс. Ко-ко-ко. А тут ты целых 16 тысяч! Висящие в памяти процессы и сетевые подключения - тормозят систему, тормозят запросы, крутят SSD диск в обратную сторону тормозят прогресс…

Писец………. и сверху смузи присыпать

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

Раве уже доказано, что проблема в количестве воркеров

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

точнее доказано, что индусы забыли на стороне приложения пул коннектов (а ля HikariCP).

Поверхностный гуглёж говорит, что в этом месте линукс O(1)тлично масштабируемый

тормоза не от большого числа процессов.

тормоза от того, как постгрес память жрет.

открываем 16 постоянных коннектов.

в ОДИН поток начинаем гонять рандомно запросы по каждому из конектов. сожрет памяти 16*work_mem*x, x > 1.

оверхед 16х.

PS анон пережрал походу сегодня…

У тебя там шаред-хостинг штоле

Судя по скудному описанию, похоже на модный SAAS.

Шутка: Говорили же: не надо хранить свои данные в облаке, теперь понятно почему.

Подожди, сейчас ОП откроет для себя виртуализациб, купит 1000 виртуалок по 512mb на другом полушарии и будет оркестрировать ансибль. В резюме напишет, что он синиор девопс архитект, знает как высоконагруженно решать проблемы масштабирования хайлоуда. Ключевая компетенция: Управление людьми.

базовая цена вопроса?

тормоза от того, как постгрес память жрет

Или от того, что ему её просто мало. Что решается отвёрткой и парой килоденег.

На 12 процессоров 64гб вообще идиотская конфигурация, в двусокетной машине-то.

Да у него общий постгрес для 1000 баз 1С, а эта фигня создаёт свои таблицы в базе под сущности описанные в конфигурации.

идиотская конфигурация

Не обязательно. Я видывал запросы похуже. Проблема в разрабах – они не хотят или не умеют считать требуемые ресурсы. Недавний пример ответа на «сколько памяти нужно жвму?» – «не ограниченно». Столько денег у нас нет, т.ч. по проду оом киляет, и никто не шевелится, ибо так производитель сказал.

Я даже для 1С не могу представить случай с таким количеством независимых конфигураций для одного, как я понимаю, предприятия. Хотя тут я совсем мимокрокодил.

Аутсорсная бухгалтерия. 50 бухгалтеров обслуживающие 100500 ИП-шников.

Мдя. Чего только не узнаешь…

Спасибо.

Но есть подозрение, что с такими масштабами и со столь специфичным продуктом они могли бы вложиться в расширение серверного железа…