| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Don Seiler <don(at)seiler(dot)us>, P C <puravc(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Estimating HugePages Requirements? |
| Date: | 2021-08-10 03:38:32 |
| Message-ID: | 20210810033832.ueaicvx34ehh7q2p@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-hackers |
Hi,
On 2021-08-09 18:58:53 -0500, Justin Pryzby wrote:
> Define shared_buffers as the exact size to be allocated/requested from the OS
> (regardless of whether they're huge pages or not), and have postgres compute
> everything else based on that. So shared_buffers=2GB would end up being 1950MB
> (or so) of buffer cache. We'd have to check that after the other allocations,
> there's still at least 128kB left for the buffer cache. Maybe we'd have to
> bump the minimum value of shared_buffers.
I don't like that. How much "other" shared memory we're going to need is
very hard to predict and depends on extensions, configuration options
like max_locks_per_transaction, max_connections to a significant
degree. This way the user ends up needing to guess at least as much as
before to get to a sensible shared_buffers.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2021-08-10 03:42:05 | Re: Estimating HugePages Requirements? |
| Previous Message | Justin Pryzby | 2021-08-09 23:58:53 | Re: Estimating HugePages Requirements? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2021-08-10 03:42:05 | Re: Estimating HugePages Requirements? |
| Previous Message | Amit Kapila | 2021-08-10 03:37:15 | Re: [bug] Logical Decoding of relation rewrite with toast does not reset toast_hash |