shared_buffers > 284263 on OS X

From: Brian Wipf <brian(at)shoptoit(dot)ca>
To: pgsql-performance(at)postgresql(dot)org
Subject: shared_buffers > 284263 on OS X
Date: 2006-11-17 00:03:21
Message-ID: B242A585-E94C-4ECA-8FA9-DCE72E1D8838@shoptoit.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

I'm trying to optimize a PostgreSQL 8.1.5 database running on an
Apple G5 Xserve (dual G5 2.3 GHz w/ 8GB of RAM), running Mac OS X
10.4.8 Server.

The queries on the database are mostly reads, and I know a larger
shared memory allocation will help performance (also by comparing it
to the performance of the same database running on a SUSE Linux box,
which has a higher shared_buffers setting).

When I set shared_buffers above 284263 (~ 2.17 GB) in the
postgresql.conf file, I get the standard error message when trying to
start the db:

FATAL: could not create shared memory segment: Cannot allocate memory
DETAIL: Failed system call was shmget(key=5432001, size=3289776128,
03600).

shmmax and shmall are set to 4GB, as can be seen by the output from
sysctl:
hw.physmem = 2147483648
hw.usermem = 1885794304
hw.memsize = 8589934592
kern.sysv.shmmax: 4294967296
kern.sysv.shmmin: 1
kern.sysv.shmmni: 32
kern.sysv.shmseg: 8
kern.sysv.shmall: 1048576

Has anyone else noticed this limitation on OS X? Any ideas on how I
might get shared_buffers higher than 284263?

Brian Wipf
<brian(at)clickspace(dot)com>

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Simon Riggs 2006-11-17 10:59:11 Re: [PERFORM] BUG #2737: hash indexing large tablefails, while btree of same index works
Previous Message Tom Lane 2006-11-16 22:48:16 Re: [PERFORM] BUG #2737: hash indexing large table fails, while btree of same index works