Re: Postgresql on an AMD64 machine - Mailing list pgsql-performance
From | Donald Courtney |
---|---|
Subject | Re: Postgresql on an AMD64 machine |
Date | |
Msg-id | 42A6014C.30108@sun.com Whole thread Raw |
In response to | Re: Postgresql on an AMD64 machine (Tom Arthurs <tarthurs@jobflash.com>) |
Responses |
Re: Postgresql on an AMD64 machine
Re: Postgresql on an AMD64 machine Re: Postgresql on an AMD64 machine |
List | pgsql-performance |
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 >> >> >>
pgsql-performance by date: