Чем Linux HugePages важны для серверов баз данных?

[Dmitry2019]

Больше спасибо за статью. У меня как раз есть проблема с ООМ на системе с БД. Но там помимо Постгреса бегут пара Томкатов и Артемис. ООМ убивает один из Томкатов раз в неделю. Попробую ваши рекомендации.

[elisoff]

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

[Dmitry2019]

К сожалению не так просто, нам нужны JMS, MQTT, WS в одном флаконе. Артемис делает это из коробки.

[erogov]

В оригинале:

A high value of work_mem is specified globally (at instance level). Users often underestimate the multiplying effect for such blanket decisions.

А у вас совершенно некорректная отсебятина:

Ограничения глобальной переменной work_mem. Например, если у вас 32Гб RAM и work_mem=1Гб, то больше 32 соединений вы никогда не запустите. Каждое соединение PostgreSQL будет выделять этот размер памяти.

Нехорошо так делать, перевод должен быть переводом.

[zuborg]

При этом разница в расходе памяти была колоссальной. Всего 61 Мб при включенном HugePages, вместо 25 Гб без него.

Это было бы верно, если бы сервер показал эти освободившиеся 25Гб как free (или buff/cache, неважно), но так не бывает. Память по прежнему занята, она выделена в пул HugePages и используется процессами PostgreSQL, просто не отображается в статистике используемой процессом памяти. Поэтому может показаться, что процесс использует всего 61МБ, а по факту он работает со всеми 25Гб, как и до этого.

[edo1h]

но вывод free с включенными и выключенными huge pages говорит о другом (если бы вы были правы, то показатель available memory был примерно одинаковым в обоих случаях)
другое дело, что в статье ничего не сказано о причинах, просто «включили huge pages — стало больше available memory».

[edo1h]

del