V
а work_mem сильно чувствителен к влиянию на производительность?)
Size: a a a
2021 January 19
am
work_mem не рекомендация, это лимит.
V
вообще это значение же не означает что каждый процесс столько памяти займет, а лишь максимально возможный размер, верно? то есть можно ее с запасом выдать, считая что все процессы одновременно не потребят столько, но и непонятно мне если 1 сессия потребила память, обратно не отдаст?
am
а work_mem сильно чувствителен к влиянию на производительность?)
На производительность сильно влияет проектирование базы и написание запросов. А ковыряние почем зря конфига редко ощутимый результат приносит.
V
На производительность сильно влияет проектирование базы и написание запросов. А ковыряние почем зря конфига редко ощутимый результат приносит.
OOMKiller пришел и процессы килял
V
shared_buffers -20Gi , work_mem - 16mb на 64г рам
am
вообще это значение же не означает что каждый процесс столько памяти займет, а лишь максимально возможный размер, верно? то есть можно ее с запасом выдать, считая что все процессы одновременно не потребят столько, но и непонятно мне если 1 сессия потребила память, обратно не отдаст?
Смотрите в документацию уже, там подробно расписано.
work_mem задает верхний лимит, после которого будет писать на диск.
work_mem задает верхний лимит, после которого будет писать на диск.
am
OOMKiller пришел и процессы килял
Um-hum. После того, как кто-то конфиг поковырял.
V
Um-hum. После того, как кто-то конфиг поковырял.
не на 128кб шаред буферов же запускаться, его все равно надо ковырять, но видимо настройки неоптимальные для нагрузки подобрали
YS
work_mem не рекомендация, это лимит.
Довольно мягкий, в таком случае. :)
Потому что это "лимит" на один plan node, и executor его всё равно проигнорирует, если не будет другого выхода.
К тому же, это значение больше используется при оценках, чем при выполнении.
Потому что это "лимит" на один plan node, и executor его всё равно проигнорирует, если не будет другого выхода.
К тому же, это значение больше используется при оценках, чем при выполнении.
am
128 мегабайт там по умолчанию.
И почему бы и нет?
Тестировали? Разницу замеряли? Нет?
И почему бы и нет?
Тестировали? Разницу замеряли? Нет?
YS
вообще это значение же не означает что каждый процесс столько памяти займет, а лишь максимально возможный размер, верно? то есть можно ее с запасом выдать, считая что все процессы одновременно не потребят столько, но и непонятно мне если 1 сессия потребила память, обратно не отдаст?
Нет, он этого не означает, к сожалению. Лучше посмотрите документацию.
am
Yaroslav Schekin
Довольно мягкий, в таком случае. :)
Потому что это "лимит" на один plan node, и executor его всё равно проигнорирует, если не будет другого выхода.
К тому же, это значение больше используется при оценках, чем при выполнении.
Потому что это "лимит" на один plan node, и executor его всё равно проигнорирует, если не будет другого выхода.
К тому же, это значение больше используется при оценках, чем при выполнении.
> если не будет другого выхода
Дык на диск писать же будет.
Дык на диск писать же будет.
YS
На производительность сильно влияет проектирование базы и написание запросов. А ковыряние почем зря конфига редко ощутимый результат приносит.
Ну да, разницы от tuning более чем в 3 раза редко удаётся добиться, это верно. ;)
YS
> если не будет другого выхода
Дык на диск писать же будет.
Дык на диск писать же будет.
Нет. Просто проигнорирует, и всё.
am
Yaroslav Schekin
Нет. Просто проигнорирует, и всё.
И шо, всю память мне сожрет, негодник?
YS
OOMKiller пришел и процессы килял
Что означает, что OS неправильно настроена, а не PostgreSQL.
См. https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
См. https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
YS
И шо, всю память мне сожрет, негодник?
В крайних случаях — сколько нужно будет, столько и использует.
И, опять-таки, даже если до этого не доходит, work_mem касается каждого узла запроса, поэтому один запрос может "съесть" и 4, и 10, 40 work_mem (зависит от сложности плана).
И, опять-таки, даже если до этого не доходит, work_mem касается каждого узла запроса, поэтому один запрос может "съесть" и 4, и 10, 40 work_mem (зависит от сложности плана).
V
Yaroslav Schekin
Что означает, что OS неправильно настроена, а не PostgreSQL.
См. https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
См. https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
ну почему ос? оом это следствие, а причина в потреблении памяти, которрое настройка постгреса регулируется, разве нет?
am
Yaroslav Schekin
В крайних случаях — сколько нужно будет, столько и использует.
И, опять-таки, даже если до этого не доходит, work_mem касается каждого узла запроса, поэтому один запрос может "съесть" и 4, и 10, 40 work_mem (зависит от сложности плана).
И, опять-таки, даже если до этого не доходит, work_mem касается каждого узла запроса, поэтому один запрос может "съесть" и 4, и 10, 40 work_mem (зависит от сложности плана).
Ну, чтобы оно в 40 потоков параллелилось — это надо настраивать уметь.