> Не вижу логики в этой формуле, если честно. Хорошо, как

правильно ограничить work_mem?

> Если к кому-то приходит OOMKiller, то этот кто-то не умеет настраивать OS под PostgreSQL, вот и всё.

Да, у нас не настроено это ещё и судя по топику админы не скоро его сделают... Вот такие вот дела.

> Хорошо, как правильно ограничить work_mem? А с какой целью? Для оптимальной производительности — это одно дело, а для того, чтобы реже падало, несмотря на профессионализм "админов" — совсем другое. ;) Далее, настройка в любом случае зависит от вида нагрузки / используемых запросов — где-то work_mem не имеет значения (там, где "классический" OLTP, например), а где-то — очень важен.

Да, поятно. В вашем ответе как всегда всё сложно. Нету простой объясняющей формулы. 😊 Я вас понимаю, зависит от нагрузки. Если предположим, что клиенты одноверемнно сделали самый неподходящий запрос, который использует work_mem для сортировки в одном statement-е (а может и не один раз), то видимо нужно примерно мою формулу брать.

Подождите. Вот это: TOTAL_MEMORY - effective_cache_size - maintenance_work_mem - OS_KERNEL_SIZE с учётом того, что (effective_cache_size = shared_memory + os cache), в норме должно давать примерно ноль, нет? Я потому и написал, что логики в этой формуле не вижу.

ну я примерно оценил, что если в os_cache будет столько-то GB постоянно (не важно, сколько клиентов и какие запросы сейчас делают), то efffective_cache_size будет такой. Понятно, что, когда клиентов меньше, общий кеш будет сильно больше. Т.е. если придёт maximum клинтов, то они не должны съесть больше чем столько-то GB памяти, а значит в os_cache останется вот это минимальное количество.

> ну я примерно оценил, что если в os_cache будет столько-то GB постоянно Хмм... сколько-то? Потому что я читаю то, что написано, а на самом деле в OS cache в норме попадает почти вся остающаяся RAM. Если Вы используете какие-то свои определения, хоть написали бы об этом. ;)

Звучит так, что effective_cache_size рассчитывается без учёта work_mem*max_connections*coefficient

У меня мысли были такие при расчете всех параметров: Выбираем shared_memory, max_connections, а остальные параметры меняются со временем. Точные значения не получить. Сделал примерно следующее: Сказал, что пусть минимум os_cache будет столько же, сколько shared_memory, т.е. shared_mem = os_cache=memory/2 Остальное отдаю под maintenance_work_mem и work_mem*max_connections. Когда коннекций максимальное число, то shared_memry=os_cache и в сумме половину памяти, когда коннекций мало, то os_cache больше. Как правильно надо мыслить?)

Что-то тут не так с формулами. Потому что вот это: shared_mem = os_cache=memory/2 (если memory = RAM) означает, что остаток = 0, нет? И да, зачем Вам такой минимальный os_cache в принципе? > Остальное отдаю под maintenance_work_mem И по какой причине Вы его считаете один раз? > и work_mem*max_connections. Опять-таки, почему? Это же не худший случай. И да, раз Вы всё равно занимаетесь "шаманством", почему бы не поставить любой work_mem (например, тот, с которым "типичные" запросы, где он нужен, работают хорошо), а потом с каждым очередным падением сервера PostgreSQL уменьшать его? ;)

Ошибся, shared_memory=os_cache=memory/4. Да, maintenance_work_mem нужно умножать на autovacuum_max_workers. И work_mem*max_connections*coefficient должен о быть. Но у нас в реальности каждый запрос не использует work_mem, поэтому я, возможно грубо, оценил coefficient = 1. > а потом с каждым очередным падением сервера PostgreSQL уменьшать его? Так правда делают?)

> поэтому я, возможно грубо, оценил coefficient = 1 Тогда, если я правильно понял, это "сойдёт" (хотя почти наверняка в реальности можно было бы поставить [существенно} больше, см. ниже). > Так правда делают?) (Ехидно) Вы будете, почти наверняка — точнее "оцените" то, что реально будет на месте max_connections и coefficient. Ну или существенная часть RAM будет почти что простаивать. И так можно легко проиграть в производительности раза в 3 и более — но на что только не пойдёшь, лишь правильно не настраивать OS, правда? ;) Кроме шуток — неужели нельзя решить этот вопрос с "админами"?

На счёт того, зачем мне такой минимальный os_cache нужен, не могу найти ответа достойного. Ощущение, что непонимаю, что нужно в effective_cache_size поставить

Хорошо, спасибо

Я к тому, что на кеш OS postgres полагается мало для каких целей, т.е. отдать эту RAM в shared_buffers почти всегда эффективнее.

Ага, спасибо. Тогда как правильно выставлять это значение (effective_cache_size)?) Просто эта настройка влияет в моём случае на использование индекса очень сильно и как оценить os_cache совершенно непонятно.

А он всё равно не очень точно учитывается, к счастью, так что и выставлять его можно довольно грубо. :) Т.е. его можно завышать (ставить хоть равным RAM), и от этого будет только лучше, скорее всего.

Спасибо!