Modifying shared_buffers causes despite plenty of ram

From: STA <iamthepants(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Modifying shared_buffers causes despite plenty of ram
Date: 2011-05-17 17:00:12
Message-ID: f5883dbc-4d38-476f-b953-b556df9c506f@l18g2000yql.googlegroups.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message STA 2011-05-17 17:02:36 Re: Modifying shared_buffers causes despite plenty of ram
Previous Message Dave Johansen 2011-05-17 15:31:04 Pushing LIMIT into sub-queries of a UNION ALL?