Добрый день. Подскажите, хочу оттюнинговать postgresql patroni с 3 нодами

на каждой по 32 гб, а именно max_connections 500. Правильно я помню, что рекомендуется еще изменить параметр shared_buffers? и его над ставить 20% от памяти на сервере. Как считать в случае кластеров? - общее количество памяти на всех нодах или только на от значения одной ноды?

> Правильно я помню, что рекомендуется еще изменить параметр shared_buffers? Да, и далеко не только его. > и его над ставить 20% от памяти на сервере. Почти наверняка нет (это где-то около наихудшей настройки для типичных "железа" и нагрузок). > Как считать в случае кластеров? Это вообще не так считается, начиная со случая одного сервера. И да, эти вот "кластеры" патрони существуют, в основном, в Вашем воображении. ;) В том смысле, что это просто "обёртка" вокруг streaming replication — и серверы ведут себя точно так же, соответственно.

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

> то есть ставить нужно 20% от озу на каждом сервере? Мне кажется, Вы не прочитали то, что я написал.

> и его над ставить 20% от памяти на сервере. -как я понимаю это есть ключевая фраза)

> Почти наверняка нет (это где-то около наихудшей настройки для типичных "железа" и нагрузок). Как Вы думаете, что означает эта фраза?

>где-то около наихудшей настройки С чего бы? Дефолт в 128M даёт обычно заметно хужэ результаты.

почти наверняка?) серьезно?) я вообще этого не понял если честно, это из разряда "ну наверно может быть")))

"С того бы", что мы тестировали (и я уже писал об этом где-то тут... и даже, кажется, Вы участвовали в обсуждении?). И да, ровно такие же результаты можно увидеть в тестировании и других людей (в т.ч. и некоторых разработчиков PostgreSQL). Нет, если кому это нравится — может "списывать" с [сильно] устаревшей документации (недочитывая её, кстати!); или пользоваться tuners, которые тоже списывают с устаревшей документации (и этого вместо того, чтобы хотя бы раз взять и померять на своей нагрузке!), и терять на этом 20-40% производительности. ;(

Не, это скорее всего из разряда "никогда".

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

Огонь! 20 лет себя ругаю, что в устной речи употребляю "наверное" как "возможно, да". Тут вдруг выявляется узус, что не только "наверное", но ужэ и "наверняка" воспринимается как "возможно", а не "верно, точно". Это несколько примиряет меня с моим языком...

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

поставь 64, проводи тесты, каждый раз увеличивая на 16 Мб, как начнётся падение производительности - остановись)

Вы никакой ситуации не описали, вот в чём дело. И да, я не вижу смысла повторять то, что я уже написал (в первом же сообщении). Если кто-то хочет помощи с tuning — во-первых, начинать надо с OS; во-вторых, приводить как минимум более-менее полные данные о "железе", версии PostgreSQL и [ожидаемой] нагрузке (особенно о виде нагрузки и размере "горячих" данных).

я бы выставил 4гб этот параметр

64мб?

А если лень? Жызнь коротка, чтобы растрачивать её на выгадывание 20% мощности сервера...

понял, спасибо) там вообще каша - ос oracle linux, 32gb на каждой ноде, в плане нагрузки не велико озу за последнее время потреблялось от 7 до 12гб, версия postgresql 14.7 64bit

>в плане нагрузки не велико Смешно. Да, вписывайте значения с pgtuner и не парьтесь — вам до начала осмысленного тэстирования скорости как до Луны.

Стикер

И, жэлательно, прекратите использовать patroni.

Так он не DBA — он сисадмин шырокого профиля. Сколько сейчас стоит DBA? Ну, тыкой, чтобы тэсты осмысленно смог написать и прочесть результаты? 300 деревянных в месяц? Плюс налоги — итого тысячи 4 долларов как минимум. 50 в год. За среднее время жызни сервера — 2-3 года — получится 150-200 тысяч. Учитывая, что это должно быть 20%, ну пусть там с двумя репликами — цэна сервера получается тысяч 700 долларов. И да, это была по сути шутка. Но такая... С долей правды.

Вот тут и не хватает информации, совсем... ни CPU, ни дисков, ни вида нагрузки, ни объёма "горячих" данных (что такое "потреблялось от 7 до 12гб" (как/чем) это измерено, я не понимаю, например)...

Ну, и вообще — сказали жэ — нагрузка невелика. Значит, что он сэкономит от 40% прироста скорости? Немного электричества хозяину датацэнтра?

Так стоимость замены же. ;) Т.е., например, был DBA за 3500, заменили "менее ленивого" DBA за 4000 (да и сама замена-то тоже не бесплатная — работают HR, несчастные собеседующие, бухгалтеры (и всё это делается вместо чего-то более полезного) и т.п.)...

Так у них ведь нет DBA! О какой замене речь идёт? Только найм...

Ну так я и не про них задумался — а так, вообще. ;)

Тем не менее — если бы была эта информация, можно было бы чего-то насоветовать, процентов на 40. ;)

почему же? это не моя инфраструктура вообще. И я давно настраивал патрони, в том месте за 3 года до сих пор как часы работает все)

Если меньшэ шутить — то обычно дажэ DBA заняты какой-то полезной работой. Вместо той полезной работы они могут делать полезную работу по проведению тэстов производительности, обучению написанию тэстов производительности и прочей девопсятине. Дело хорошэе... Но вобще-то реально трудозатратное. И если посмотреть, сколько времени и зарплаты это займёт, и сколько сэкономит денег с одного, допустим, сервера/проекта — то всё равно получаются какие-то тысячи долларов первое число, и не факт что хотя бы столько жэ — второе.

Как часы — это только время показывает?

Вот мне и кажется, что "не факт", и сходу не посчитаешь...

А насчёт "почему" — сколько failover оно провело, какой был итоговый downtime (всего), какой — в процэссе fail, приведшым к failover, какие из них были лишними (downtime был бы меньшэ без failover), сколько данных было потеряно благодаря failover и как восстановлены, сколько было потеряно по другим причинам?

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

да нет, там полно народу работает с этими данными