Message-ID: <4DBDB6CB.70002@2ndQuadrant.com>
Date: Sun, 01 May 2011 15:38:51 -0400
From: Greg Smith <greg@2ndQuadrant.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: The right SHMMAX and FILE_MAX
References: <BANLkTinCr_+Hs_zzHPb+tBdtuLFhrsfKdg@mail.gmail.com>
In-Reply-To: <BANLkTinCr_+Hs_zzHPb+tBdtuLFhrsfKdg@mail.gmail.com>
Content-Type: multipart/mixed; boundary="------------010206010704090302060803"

This is a multi-part message in MIME format.
--------------010206010704090302060803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 05/01/2011 02:48 AM, Phoenix Kiula wrote:
> Hi. I'm on a 64 Bit CentOS 5 system, quadcore processor, 8GB RAM and
> tons of data storage (1 TB SATAII disks).
>
> The current SHMMAX and SHMMIN are (commas added for legibility) --
>
> kernel.shmmax = 68,719,476,736
> kernel.shmall = 4,294,967,296
>    

That's set higher than the amount of RAM in the server.  Run the 
attached script; it will produce reasonable values for your server, 
presuming you'll never want to allocate >50% of the RAM in the server 
for shared memory.  Given standard tuning for shared_buffers is <40%, 
I've never run into a situation where this was a terrible choice if you 
want to just set and forget about it.  Only reason to fine-tine is if 
another major user of shared memory is running on the server

> Now, according to my reading in the PG manual and this list, a good
> recommended value for SHMMAX is
>
>     (shared_buffers * 8192)
>    

The value for shared_buffers stored internally is in 8192 byte pages:

select setting,unit,current_setting(name) from pg_settings where 
name='shared_buffers';
  setting | unit | current_setting
---------+------+-----------------
  4096    | 8kB  | 32MB

So any formula you found that does this sort of thing is just converting 
it back to bytes again, and is probably from an earlier PostgreSQL 
version where you couldn't set this parameter in memory units.  SHMMAX 
needs to be a bit bigger than shared_buffers in bytes.

> Similarly with "fs.file_max". There are articles like this one:
> http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec72.html
> Is this relevant for PostgreSQL performance at all, or should I skip that?
>    

That's ancient history.  This is how big the default is on the two Linux 
distributions I have handy:

[RHEL5]
$ cat /proc/sys/fs/file-max
745312

[Debian Squeeze]
$ cat /proc/sys/fs/file-max
1645719

It was a tiny number circa the RedHat 6 that manual was written for, now 
it's very unlikely you'll exceed the kernel setting here.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


--------------010206010704090302060803
Content-Type: text/plain;
 name="shmsetup"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="shmsetup"

#!/bin/bash

# Output lines suitable for sysctl configuration based
# on total amount of RAM on the system.  The output
# will allow up to 50% of physical memory to be allocated
# into shared memory.

# On Linux, you can use it as follows (as root):
# 
# ./shmsetup >> /etc/sysctl.conf
# sysctl -p

# Early FreeBSD versions do not support the sysconf interface
# used here.  The exact version where this works hasn't
# been confirmed yet.

page_size=`getconf PAGE_SIZE`
phys_pages=`getconf _PHYS_PAGES`

if [ -z "$page_size" ]; then
  echo Error:  cannot determine page size
  exit 1
fi

if [ -z "$phys_pages" ]; then
  echo Error:  cannot determine number of memory pages
  exit 2
fi

shmall=`expr $phys_pages / 2`
shmmax=`expr $shmall \* $page_size` 

echo \# Maximum shared segment size in bytes
echo kernel.shmmax = $shmmax
echo \# Maximum number of shared memory segments in pages
echo kernel.shmall = $shmall

--------------010206010704090302060803--