Date: Tue, 07 Jun 2005 16:19:24 -0400
From: Donald Courtney <Donald.Courtney@Sun.COM>
Subject: Re: Postgresql on an AMD64 machine
In-reply-to: <42A5FB70.8090807@jobflash.com>
To: Tom Arthurs <tarthurs@jobflash.com>
Cc: pgsql-performance@postgresql.org
Message-id: <42A6014C.30108@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221
References: <1118080420.1644.23.camel@penguin1>
	<b918cf3d05060613593a73a18a@mail.gmail.com> <42A5F7B6.20502@sun.com>
	<42A5FB70.8090807@jobflash.com>

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@bowmansystems.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
>>
>>
>>