Re: Postgresql on an AMD64 machine

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 <mark(at)bowmansystems(dot)com>
>>>> 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
>>>
>>>
>>>
>
>
>
>