Re: PostgreSQL's share_buffer calculation using shmget() versus kernel.shmmax - Mailing list pgsql-admin

From Tom Lane
Subject Re: PostgreSQL's share_buffer calculation using shmget() versus kernel.shmmax
Date
Msg-id 27677.1360216169@sss.pgh.pa.us
Whole thread Raw
In response to Re: PostgreSQL's share_buffer calculation using shmget() versus kernel.shmmax  (Mel Llaguno <mllaguno@coverity.com>)
Responses Re: PostgreSQL's share_buffer calculation using shmget() versus kernel.shmmax
List pgsql-admin
Mel Llaguno <mllaguno@coverity.com> writes:
> Thanks for your reply. I agree with your statement that you should set the configuration parameters first, but I
wouldlike to be able to calculate the SHMMAX value based on those parameters. This is particularly useful when
suggestingpostgresql.conf optimizations to our customers whose machine have a lot of RAM (64+GB). Having to guess this
valueis far from ideal; what I'd like is the formula used by postgresql that generates the shmget() value displayed in
thepgctl.log. 

There's some rather old information in Table 17-2 here:
http://www.postgresql.org/docs/9.2/static/kernel-resources.html#SYSVIPC

As Pavan says, the shared_buffers term is usually the only one worth
worrying about.  The traditional advice is to not set that to more than
about a quarter of your physical RAM, which would mean that this script
you're using to set SHMMAX is leaving lots of headroom, which is
perfectly OK.  (AFAIK there is no penalty to setting SHMMAX larger than
you need.)

There's more info worth looking at here:
https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

            regards, tom lane


pgsql-admin by date:

Previous
From: Mel Llaguno
Date:
Subject: Re: PostgreSQL's share_buffer calculation using shmget() versus kernel.shmmax
Next
From: Mel Llaguno
Date:
Subject: Re: PostgreSQL's share_buffer calculation using shmget() versus kernel.shmmax