From: | Andy Fan <zhihuifan1213(at)163(dot)com> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me> |
Cc: | DBA <ecountdba(at)ecounterp(dot)co(dot)kr>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: what are the things that occupy the session memory. |
Date: | 2024-10-06 04:19:46 |
Message-ID: | 87zfnhkgm5.fsf@163.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tomas Vondra <tomas(at)vondra(dot)me> writes:
> Anyway, I agree shared buffers 70GB is way too high - I'd reduce that to
> maybe 8GB and only increase that if cache hit ratio is below 0.95 or
> so.
I'm always confused how should shared_buffers be set initially (saying
monitor and adjust them later is not free.) Some places say 25% of
physical memory but I don't know why is that. I'm not sure my question
can have a answer, but just have a try. The known drawback of big shared
buffer from me includes: a). Seize the memory from other
component which may contribute to OOM. b). make some operation
slower. e.g. drop / truncate table.
> If not, try reducing work_mem. If you're doing OLTP queries, those
> likely don't need wm=300MB (why did you set this value?). For OLAP
> queries 300MB might make sense, but then maybe you shouldn't have 300 of
> them.
I want to have a metion of autovacuum_work_mem/maintenance_work_mem for
a OLTP workload. In OLTP workload, user probably doesn't need a bigger
work_mem but if user set it to a bigger value, it should not cause a big
issue IIUC, since it just set a upper bound. However in OLTP workload, it
probably has lots of updates/delete, and if they have lots of tables, it
probably use up to {autovacuum_work_mem} memory per vacuum worker, which
is more likely cause an issue.
--
Best Regards
Andy Fan
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Wienhold | 2024-10-06 14:49:49 | Re: Error when setting default_text_search_config |
Previous Message | Cameron Vogt | 2024-10-05 22:11:54 | Re: PostgreSQL 17 Segmentation Fault |