Re: What's the best hardver for PostgreSQL 8.1? - Mailing list pgsql-performance

On Thu, 22 Dec 2005, Juan Casero wrote:

> Ok thanks.  I think I will go with 64 bit everything on the box.  If I can get
> the Sun Fire V20Z then I will stick with Solaris 10 x86 and download the 64
> bit PostgreSQL 8.1 binaries from blastwave.org.   I develop the PHP code to
> my DSS system on my Windows XP laptop.  Normally, I test the code on this
> laptop but let it hit the live database when I want to run some tests.  Well
> just this afternoon I installed PostgreSQL 8.1.1 on my windows laptop and
> rebuilt the the entire live database instance on there from a pg_dump
> archive.   I am blown away by the performance increase in PostgreSQL 8.1.x.
> Has anyone else had a chance to test it?   All the queries I run against it
> are remarkably fast but more importantly I can see that the two cores of my
> Hyper Threaded P4 are being used.   One of the questions I posted on this
> list was whether PostgreSQL could make use of the large number of cores
> available on the Ultrasparc T1000/T2000 cores.  I am beginning to think that
> with PostgreSQL 8.1.x the buffer manager could indeed use all those cores.
> This could make running a DSS or OLTP on an Ultrasparc T1000/T2000 with
> PostgreSQL a much better bargain than on an intel system.  Any thoughts?

if you have enough simultanious transactions, and your I/O systems (disk
and memory interfaces) can keep up with your needs then postgres can use
quite a few cores.

there are some limits that will show up with more cores, but I don't think
it's well known where they are (this will also be very dependant on your
workload as well). there was the discussion within the last month or two
that hit the postgres weekly news where more attention is being paied to
the locking mechanisms used so this is an area under active development
(note especially that some locking strategies that work well with multiple
full cores can be crippling with virtual cores (Intel HT etc).

but it boils down to the fact that there just isn't enough experiance with
the new sun systems to know how well they will work. they could end up
being fabulous speed demons, or dogs (and it could even be both, depending
on your workload)

David Lang

> Thanks,
> Juan
>
> On Thursday 22 December 2005 22:12, David Lang wrote:
>> On Wed, 21 Dec 2005, Juan Casero wrote:
>>> Date: Wed, 21 Dec 2005 22:31:54 -0500
>>> From: Juan Casero <caseroj@comcast.net>
>>> To: pgsql-performance@postgresql.org
>>> Subject: Re: [PERFORM] What's the best hardver for PostgreSQL 8.1?
>>>
>>> Sorry folks.  I had a couple of glasses of wine as I wrote this.  Anyway
>>> I originally wanted the box to have more than two drives so I could do
>>> RAID 5 but that is going to cost too much.  Also, contrary to my
>>> statement below it seems to me I should run the 32 bit postgresql server
>>> on the 64 bit kernel. Would you agree this will probably yield the best
>>> performance?
>>
>> you definantly need a 64 bit kernel to address as much ram as you will
>> need.
>>
>> the question of 32 bit vs 64 bit postgres needs to be benchmarked, but my
>> inclination is that you probably do want 64 bit for that as well.
>>
>> 64 bit binaries are slightly larger then 32 bit ones (less so on x86/AMD64
>> then on any other mixed platform though), but the 64 bit version also has
>> access to twice as many registers as a 32 bit one, and the Opteron chips
>> have some other features that become availabel in 64 bit mode (or more
>> useful)
>>
>> like everything else this needs benchmarks to prove with your workload
>> (I'm trying to get some started, but haven't had a chance yet)
>>
>> David Lang
>>
>>> I know it
>>> depends alot on the system but for now this database is about 20
>>> gigabytes. Not too large right now but it may grow 5x in the next year.
>>>
>>> Thanks,
>>> Juan
>>>
>>> On Wednesday 21 December 2005 22:09, Juan Casero wrote:
>>>> I just sent my boss an email asking him for a Sun v20z with dual 2.2 Ghz
>>>> opterons, 2 Gigs of RAM and RAID 1.  I would have liked a better server
>>>> capable of RAID but that seems to be out of his budget right now.  Ok so
>>>> I assume I get this Sun box.  Most likely I will go with Linux since it
>>>> is a fair bet he doesn't want to pay for the Solaris 10 x86 license.
>>>> Although I kind of like the idea of using Solaris 10 x86 for this.   I
>>>> will assume I need to install the x64 kernel that comes with say Fedora
>>>> Core 4.  Should I run the Postgresql 8.x binaries in 32 bit mode or 64
>>>> bit mode?   My instinct tells me 64 bit mode is most efficient for our
>>>> database size about 20 gigs right now but may grow to 100 gigs in a year
>>>> or so.  I just finished loading a 20 gig database on a dual 900 Mhz
>>>> Ultrasparc III system with 2 gigs of ram and about 768 megs of shared
>>>> memory available for the posgresql server running Solaris 10.  The load
>>>> has smoked a P4 3.2 Ghz system I am using also with 2 gigs of ram
>>>> running postgresql 8.0.3.   I mean I started the sparc load after the P4
>>>> load.  The sparc load has finished already rebuilding the database from
>>>> a pg_dump file but the P4 system is still going.  The p4 has 1.3 Gigs of
>>>> shared memory allocated to postgresql.  How about them apples?
>>>>
>>>>
>>>> Thanks,
>>>> Juan
>>>>
>>>> On Wednesday 21 December 2005 18:57, William Yu wrote:
>>>>> Juan Casero wrote:
>>>>>> Can you elaborate on the reasons the opteron is better than the Xeon
>>>>>> when it comes to disk io?   I have a PostgreSQL 7.4.8 box running a
>>>>>> DSS.   One of our
>>>>>
>>>>> Opterons have 64-bit IOMMU -- Xeons don't. That means in 64-bit mode,
>>>>> transfers to > 4GB, the OS must allocated the memory < 4GB, DMA to that
>>>>> block and then the CPU must do extra work in copying the memory to >
>>>>> 4GB. Versus on the Opteron, it's done by the IO adaptor using DMA in
>>>>> the background.
>>>>>
>>>>> ---------------------------(end of
>>>>> broadcast)--------------------------- TIP 6: explain analyze is your
>>>>> friend
>>>>
>>>> ---------------------------(end of broadcast)---------------------------
>>>> TIP 1: if posting/reading through Usenet, please send an appropriate
>>>>        subscribe-nomail command to majordomo@postgresql.org so that your
>>>>        message can get through to the mailing list cleanly
>>>
>>> ---------------------------(end of broadcast)---------------------------
>>> TIP 2: Don't 'kill -9' the postmaster
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 2: Don't 'kill -9' the postmaster
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
>