icps, shmmax and shmall - Shared Memory tuning

pgsql-general users -

background: rh6.1 (glibc 2.1.3), SMP p3-600, 512MB
RAM, postgres 7.2.1, kernel 2.4.17

My postgres server decided to act up this morning, and
I discovered this in the logs -

Apr 26 09:34:16 mito logger: ^IThe Postmaster has
informed me that some other backend
Apr 26 09:34:16 mito logger: ^Idied abnormally and
possibly corrupted shared memory.
Apr 26 09:34:16 mito logger: ^II have rolled back the
current transaction and am
Apr 26 09:39:54 mito logger: ^Igoing to terminate your
database system connection and exit.
Apr 26 09:43:16 mito logger: IpcMemoryCreate:
shmget(key=5432001, size=137175040, 03600) failed:
Invalid
argument
Apr 26 09:43:16 mito logger:
Apr 26 09:43:16 mito logger: This error usually means
that PostgreSQL's request for a shared memory
Apr 26 09:43:16 mito logger: segment exceeded your
kernel's SHMMAX parameter.  You can either
Apr 26 09:43:16 mito logger: reduce the request size
or reconfigure the kernel with larger SHMMAX.
Apr 26 09:43:16 mito logger: To reduce the request
size (currently 137175040 bytes), reduce
Apr 26 09:43:16 mito logger: PostgreSQL's
shared_buffers parameter (currently 16000) and/or
Apr 26 09:43:16 mito logger: its max_connections
parameter (currently 256).
Apr 26 09:43:16 mito logger:
Apr 26 09:43:16 mito logger: If the request size is
already small, it's possible that it is less than
Apr 26 09:43:16 mito logger: your kernel's SHMMIN
parameter, in which case raising the request size or
Apr 26 09:43:17 mito logger: reconfiguring SHMMIN is
called for.
Apr 26 09:43:17 mito logger:
Apr 26 09:43:17 mito logger: The PostgreSQL
Administrator's Guide contains more information about
Apr 26 09:43:17 mito logger: shared memory
configuration.

The box has 512MB RAM, and so I set the following per
the tuning docs (and some mailing list information ) -

echo "201326592" > /proc/sys/kernel/shmmax
/sbin/sysctl -w kernel.shmmax=201326592
echo "201326592" > /proc/sys/kernel/shmall
/sbin/sysctl -w kernel.shmall=201326592

But when I run 'ipcs -l', it lists the shmall (total)
as ~800MB. Is this correct, or s there something else
I need to do? I've seen some mentions of using 'ipcrm'
to clear out stale segments, but I've not seen any
pages describing how to do this in a real-world
situation.

# ipcs -l

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 196608
** max total shared memory (kbytes) = 805306368 **
min seg size (bytes) = 1

------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767

------ Messages: Limits --------
max queues system wide = 16
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

Here's the output from 'ipcs -m' -

------ Shared Memory Segments --------
key       shmid     owner     perms     bytes
nattch    status
0x00000000 0         nobody    600       46084     13
      dest
0x00000000 32769     nobody    600       46084     6
      dest
0x00000000 65538     nobody    600       46084     3
      dest
0x0052e2c1 98307     postgres  600       137175040 28

0x00000000 131076    nobody    600       46084     5
      dest

Is this the output I should expect, or am I missing
something? I'm not entirely fluent in fine-tuning
shared memory, so I certainly appreciate any help you
can offer.

If you have any other tuning tips for my setup, I'm
always open to suggestions.

-d

__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/