Yes, shared buffers in postgres are not used for caching -- unlike Oracle. Every time we hire an Oracle dba, I have to break them of the notion (which I shared when I started with postgres -- Josh Berkus and Josh Drake helped burst that bubble for me) :)

You should gain i/o reduction through increasing kernel buffers -- Postgresql counts on read/write caching through that, so increasing that should get your performance improvemnets -- though I haven't found the sweet spot there yet, for solaris. My biggest challenge with solaris/sparc is trying to reduce context switching.

Donald Courtney wrote:
Tom Arthurs wrote:

According to my research, you only need a 64 bit image if you are going to be doing intensive floating point operations (which most db servers don't do). Some benchmarking results I've found on the internet indicate that 64 bit executables can be slower than 32 bit versions. I've been running 32 bit compiles on solaris for several years.

How much memory do you have on that sparc box? Allocating more than about 7-12% to shared buffers has proven counter productive for us (it slows down).

The system has 8 CPUs w/ 32 GB - I'm hoping to see some benefit to large caches -
Am I missing something key with postgreSQL?
Yes - we have seen with oracle 64 bit that there can be as much as a 10% hit moving from 32 - but we make it up big time with large db-buffer sizes that drastically
reduce I/O and allow for other things (like more connections).  Maybe
the expectation of less I/O is not correct?

Don

P.S.  built with the Snapshot from two weeks ago.

Kernel buffers are another animal. :)

Donald Courtney wrote:

Get FATAL when starting up (64 bit) with large shared_buffers setting

I built a 64 bit for Sparc/Solaris easily but I found  that the
startup of postmaster generates a FATAL diagnostic due to going
over the 2GB limit (3.7 GB).

When building for 64 bit is there some other
things that must change in order to size UP the shared_buffers?

Thanks.

Don C.

P.S.  A severe checkpoint problem I was having was fixed with
"checkpoint_segments=200".


Message:

FATAL: 460000 is outside the valid range for parameter "shared_buffers" (16 .. 262143)
LOG:  database system was shut down at 2005-06-07 15:20:28 EDT

Mike Rylander wrote:

On 06 Jun 2005 12:53:40 -0500, Mark Rinaudo <[EMAIL PROTECTED]> wrote:
I'm not sure if this is the appropriate list to post this question to
but i'm starting with this one because it is related to the performance
of Postgresql server.  I have a Penguin Computing dual AMD 64 bit
opteron machine with 8 Gigs of memory.  In my attempt to increase the
number of shared_buffers from the default to 65000 i was running into a
semget error when trying to start Postgresql. After reading the
documentation I adjusted the semaphore settings in the kernel to allow
Postgresql to start successfully. With this configuration running if I
do a ipcs -u i get the following.





On my HP-585, 4xOpteron, 16G RAM, Gentoo Linux (2.6.9):

$ ipcs -u i

------ Shared Memory Status --------
segments allocated 1
pages allocated 34866
pages resident  31642
pages swapped   128
Swap performance: 0 attempts     0 successes

------ Semaphore Status --------
used arrays = 7
allocated semaphores = 119

------ Messages: Status --------
allocated queues = 0
used headers = 0
used space = 0 bytes


Did you perhaps disable spinlocks when compiling PG?



---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

              http://www.postgresql.org/docs/faq








---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to