Modifying shared_buffers causes despite plenty of ram - Mailing list pgsql-performance

From STA
Subject Modifying shared_buffers causes despite plenty of ram
Date
Msg-id f5883dbc-4d38-476f-b953-b556df9c506f@l18g2000yql.googlegroups.com
Whole thread Raw
List pgsql-performance
Hi - Linux newbie here, and more of a developer than pgsql SysAdmin...

When trying to follow some performance tuning suggestions by Robert
Haas here:
http://www.linux.com/learn/tutorials/394523-configuring-postgresql-for-pretty-good-performance

This is with PgSql 9.0.3 running on the Amazon EC2 on a Ubuntu 10.10
box (EBS instance with an EBS raid0 array).

I've run into a problem where increasing shared_buffers past say 10MB
causes a  "UTC FATAL" error on startup (this is with it set to 50MB,
and I only have max_connections set to 50 as I'm using connection
pooling):

2011-05-17 16:53:38 UTC FATAL:  could not create shared memory
segment: Invalid argument
2011-05-17 16:53:38 UTC DETAIL:  Failed system call was
shmget(key=5432001, size=56934400, 03600).
2011-05-17 16:53:38 UTC HINT:  This error usually means that
PostgreSQL's request for a shared memory segment exceeded your
kernel's SHMMAX parameter.  You can either reduce the request size or
reconfigure the kernel with larger SHMMAX.  To reduce the request size
(currently 56934400 bytes), reduce PostgreSQL's shared_buffers
parameter (currently 6400) and/or its max_connections parameter
(currently 54).
        If the request size is already small, it's possible that it is
less than your kernel's SHMMIN parameter, in which case raising the
request size or reconfiguring SHMMIN is called for.
        The PostgreSQL documentation contains more information about
shared memory configuration.


Here is the result of free -t -m:
             total       used       free     shared    buffers
cached
Mem:          7468       7425         43          0          7
7030
-/+ buffers/cache:        387       7081
Swap:            0          0          0
Total:        7468       7425         43

and vmstat:
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us
sy id wa
 0  0      0  50812   7432 7192808    0    0     5    50    5    5  1
0 98  0

You can see that 7081MB are used by the cache. In other examples of
top / free / vmstat I haven't seen anyone else with such a large
amount of ram in the cache column. Could that be what's keeping the
postgresql service from starting after adjusting shared_buffers? If
so, do I need to go to the Linux group to figure out how to let
Postgresql acquire that memory space on startup?

Thanks very much,
STA

pgsql-performance by date:

Previous
From: STA
Date:
Subject: Re: Modifying shared_buffers causes despite plenty of ram
Next
From: STA
Date:
Subject: Re: Modifying shared_buffers causes despite plenty of ram