Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U3KMZ-00078v-W9 for pgsql-admin@arkaria.postgresql.org; Thu, 07 Feb 2013 05:49:36 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1U3KMZ-00049O-1i for pgsql-admin@arkaria.postgresql.org; Thu, 07 Feb 2013 05:49:35 +0000 Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U3KMY-00049J-Ej for pgsql-admin@postgresql.org; Thu, 07 Feb 2013 05:49:34 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U3KMW-0002QS-Hi for pgsql-admin@postgresql.org; Thu, 07 Feb 2013 05:49:34 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id r175nT6s027678; Thu, 7 Feb 2013 00:49:29 -0500 (EST) From: Tom Lane To: Mel Llaguno cc: Pavan Deolasee , "pgsql-admin@postgresql.org" Subject: Re: PostgreSQL's share_buffer calculation using shmget() versus kernel.shmmax In-reply-to: References: , Comments: In-reply-to Mel Llaguno message dated "Thu, 07 Feb 2013 05:31:18 +0000" Date: Thu, 07 Feb 2013 00:49:29 -0500 Message-ID: <27677.1360216169@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org Mel Llaguno writes: > Thanks for your reply. I agree with your statement that you should set the configuration parameters first, but I would like to be able to calculate the SHMMAX value based on those parameters. This is particularly useful when suggesting postgresql.conf optimizations to our customers whose machine have a lot of RAM (64+GB). Having to guess this value is far from ideal; what I'd like is the formula used by postgresql that generates the shmget() value displayed in the pgctl.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 -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin