Skip site navigation (1) Skip section navigation (2)

Re: Memory Allocation (8 GB shared buffer limit on Ubuntu Hardy)

From: "Frank Joerdens" <frank(at)joerdens(dot)de>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Ryan Hansen" <ryan(dot)hansen(at)brightbuilders(dot)com>, pgsql-performance(at)postgresql(dot)org, "Nic Ferrier" <nic(at)woome(dot)com>, "Mike Rogers" <mikero(at)woome(dot)com>
Subject: Re: Memory Allocation (8 GB shared buffer limit on Ubuntu Hardy)
Date: 2009-01-07 02:20:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Tom Lane wrote:
> "Ryan Hansen" <ryan(dot)hansen(at)brightbuilders(dot)com> writes:
>> but when I set the shared buffer in PG and restart
>> the service, it fails if it's above about 8 GB.
> Fails how?  And what PG version is that?

The thread seems to end here as far as the specific question was
concerned. I just ran into the same issue though, also on Ubuntu Hardy
with PG 8.2.7 - if I set shared buffers to 8 GB, starting the server
fails with

2009-01-06 17:15:09.367 PST 6804   DETAIL:  Failed system call was
shmget(key=5432001, size=8810725376, 03600).

then I take the request size value from the error and do

echo 8810725376 > /proc/sys/kernel/shmmax

and get the same error again. If I try that with shared_buffers = 7 GB
(setting shmmax to 7706542080), it works. Even if I double the value
for 8 GB and set shmmax to 17621450752, I get the same error. There
seems to be a ceiling.

Earlier in this thread somebody mentioned they had set shared buffers
to 24 GB on CentOS, so it seems to be a platform issue.

I also tried to double SHMMNI, from 4096 -> 8192, as the PG error
suggests, but to no avail.

This is a new 16-core Dell box with 64 GB of RAM and a mid-range
controller with 8 spindles in RAID 0+1, one big filesystem. The
database is currently 55 GB in size with a web application type OLTP
load, doing ~6000 tps at peak time (and growing fast).

The problem surfaced here because we just upgraded from an 8-core
server with 16 GB RAM with very disappointing results initially. The
new server would go inexplicably slow near peak time, with context
switches ~100k and locks going ballistic. It seemed worse than on the
smaller machine.

Until we revised the configuration which I'd just copied over from the
old box, and adjusted shared_buffers from 2 GB -> 4 GB. Now it seem to
perform well. I found that surprising given that 2 GB is quite a lot
already and since I'd gathered that the benefits of cranking up shared
buffers are not scientifically proven, or that often if not most of
the time the OS's caching mechanisms are adequate or even superior to
what you might achieve by fiddling with the PG configuration and
setting shared buffers very high.




pgsql-performance by date

Next:From: Tom LaneDate: 2009-01-07 02:23:13
Subject: Re: Memory Allocation (8 GB shared buffer limit on Ubuntu Hardy)
Previous:From: David ReesDate: 2009-01-06 23:33:09
Subject: Re: understanding postgres issues/bottlenecks

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group