Re: shared_buffers > 284263 on OS X
| От | Brian Wipf |
|---|---|
| Тема | Re: shared_buffers > 284263 on OS X |
| Дата | |
| Msg-id | 817D9C4C-05F0-45FB-9D63-B63CFE2C009E@clickspace.com обсуждение исходный текст |
| Ответ на | Re: shared_buffers > 284263 on OS X (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: shared_buffers > 284263 on OS X
Re: shared_buffers > 284263 on OS X |
| Список | 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 по дате отправления: