Данная статья по настройкам памяти именно внутри Postgres'a, чтобы у пользователя было понимание как и что устроено. Стратегии overcommit в данном случае относятся косвенно. Вопрос лишь в том, целиком ли postmaster срубит OOM или только какой-то отдельный процесс.

rinace 29 окт в 17:34

Ну вообще то этот вопрос

Вопрос лишь в том, целиком ли postmaster срубит OOM или только какой-то отдельный процесс.

напрямую влияет на бизнес

Вы как рекомендуете настраивать ?

AQIS 29 окт в 18:19

Тут в целом есть тонкости, то со своей колокольни, я бы отключал overcommit (т.е. стратегия OVERCOMMIT_NEVER), а vm.overcommit_ratio равным 80-90. Можно вообще запретить OOM киллеру трогать PG, но зачем...

rinace 29 окт в 17:29

А вот этот момент тоже очень интересен

work_mem — параметр, который задаёт базовый максимальный объём памяти, который будет использоваться в рамках одного рабочего процесса (сессии) во внутренних операциях типа соединений, сортировки, группировки и т. п. при обработке запросов, прежде чем будут задействованы временные файлы на диске.

Но, как говорится - "есть один момент"(с).

work_mem (integer) #
Задаёт базовый максимальный объём памяти, который будет использоваться во внутренних операциях при обработке запросов (например, для сортировки или хеш-таблиц), прежде чем будут задействованы временные файлы на диске. Если это значение задаётся без единиц измерения, оно считается заданным в килобайтах. Значение по умолчанию — четыре мегабайта (4MB). Заметьте, что в сложных запросах одновременно могут выполняться несколько операций сортировки и хеширования, и при этом примерно этот объём памяти может использоваться в каждой операции, прежде чем данные начнут вытесняться во временные файлы. Кроме того, такие операции могут выполняться одновременно в разных сеансах. Таким образом, общий объём памяти может многократно превосходить значение work_mem; это следует учитывать, выбирая подходящее значение. Операции сортировки используются для ORDER BY, DISTINCT и соединений слиянием. Хеш-таблицы используются при соединениях и агрегировании по хешу, мемоизации узлов, а также обработке подзапросов IN с применением хеша.

koloskovv 29 окт в 17:54

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

rinace 29 окт в 17:31

А можно с этого места тоже поподробнее

Блокировки: Долгие операции автovacuum могут вызвать блокировки на таблицах, которые они обрабатывают.

О каких именно блокировках идет речь ?

koloskovv 29 окт в 17:58

Речь идет о блокировках на автообновлении статистик (на скрине видно). Новые еще не пересчитаны, а старые использовать нельзя. Они кратковременные.
Аналогичное поведение и в MS - https://habr.com/ru/companies/softpoint/articles/823250/

rinace 29 окт в 17:45

Шаг 2. Выбор shared_buffers
Параметр shared_buffers, наверное, самый понятный из всех и, фактически, представляет собой константу, которую очень легко оценить — правильно она выбрана или нет.
Для этого анализируем профиль нагрузки в части использования дисковой подсистемы для выполнения запросов.

А с ситуацией "размер shared_buffer слишком большой " - ни разу не сталкивались?

koloskovv 29 окт в 18:00

Не сталкивались, потому что им легко управлять. Обычно ставят 30% от ОЗУ - по умолчанию, поэтому у клиентов изначально такой проблемы быть не может. Далее из анализа это значение можно скорректировать.

rinace 30 окт в 06:29

Мне всегда любопытно было откуда берутся эти цифры 25% , 30% ?

Почему не 60%, 55% , 40%, 42 например , очень хорошая цифра .

Далее из анализа

А вот с этого места и начинается самое интересное :

Какие действия понимаются термином "анализ"?
Анализ каких данных ?

koloskovv 30 окт в 10:23

Мне всегда любопытно было откуда берутся эти цифры 25% , 30% ?

Это просто некая величина, возможно даже подходящая многим - средняя по больнице, которую переносят из статьи в статью )). Но мы ее рассматриваем лишь как точку старта(!). А далее анализируем профиль нагрузки в части доли использования дисковой подсистемы при выполнении запросов. Для этого используем Perfexpert, т.к. в нем есть и счетчик Cache hit ratio, и трассы тяжелых запросов.

Процитирую кусок статьи:

Shared_buffers. После выбора первоначального значения оцениваем вероятностное попадание данных в кэш с помощью счетчика Cache hit ratio. Увеличиваем память, если показания счетчика часто опускаются ниже 80%. Дополнительно оцениваем в трассах тяжелых запросов те, которые больше всего «выгрызают» данных с диска и пытаемся их оптимизировать.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий