Re: shared_buffers > 284263 on OS X - Mailing list pgsql-performance

From Brian Wipf
Subject Re: shared_buffers > 284263 on OS X
Date
Msg-id 817D9C4C-05F0-45FB-9D63-B63CFE2C009E@clickspace.com
Whole thread Raw
In response to Re: shared_buffers > 284263 on OS X  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: shared_buffers > 284263 on OS X  (Guido Neitzer <lists@event-s.net>)
Re: shared_buffers > 284263 on OS X  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-performance
On 18-Nov-06, at 11:30 AM, Tom Lane wrote:
> Dave Cramer <pg@fastcrypt.com> writes:
>> On 16-Nov-06, at 7:03 PM, Brian Wipf wrote:
>>> Has anyone else noticed this limitation on OS X? Any ideas on how I
>>> might get shared_buffers higher than 284263?
>
>> My guess is something else has taken shared memory ahead of you. OS X
>> seems to be somewhat strange in how it deals with shared memory. Try
>> allocating more to shmmax ?
>
> Look in "ipcs -m -a" output to check this theory.  (I am glad to see
> that ipcs and ipcrm are finally there in recent OS X releases ---
> awhile
> back they were not, leaving people to fly entirely blind while dealing
> with issues like this :-()

ipcs -m -a
Shared Memory:
T     ID     KEY        MODE       OWNER    GROUP  CREATOR   CGROUP
NATTCH  SEGSZ  CPID  LPID   ATIME    DTIME    CTIME
m 196607    5432001 --rw------- postgres postgres postgres
postgres      8 -2100436992    223    223 23:00:07  2:49:44 23:00:07

(I also bumped shmmax and shmall to 6GB with the same shared_buffers
limit.)

It certainly is unfortunate if Guido's right and this is an upper
limit for OS X. The performance benefit of having high shared_buffers
on our mostly read database is remarkable.


pgsql-performance by date:

Previous
From: Richard Troy
Date:
Subject: Re: Postgres server crash
Next
From: "rakesh kumar"
Date:
Subject: Fwd: start up cost estimate