From: | Brian Wipf <brian(at)clickspace(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dave Cramer <pg(at)fastcrypt(dot)com>, pgsql-performance(at)postgresql(dot)org, Guido Neitzer <lists(at)event-s(dot)net> |
Subject: | Re: shared_buffers > 284263 on OS X |
Date: | 2006-11-19 03:13:26 |
Message-ID: | 817D9C4C-05F0-45FB-9D63-B63CFE2C009E@clickspace.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 18-Nov-06, at 11:30 AM, Tom Lane wrote:
> Dave Cramer <pg(at)fastcrypt(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | rakesh kumar | 2006-11-19 04:05:08 | Fwd: start up cost estimate |
Previous Message | Richard Troy | 2006-11-19 01:28:46 | Re: Postgres server crash |