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

From David Lang
Subject Re: What's the best hardver for PostgreSQL 8.1?
Date
Msg-id Pine.LNX.4.62.0512221908120.2807@qnivq.ynat.uz
Whole thread Raw
In response to Re: What's the best hardver for PostgreSQL 8.1?  (Juan Casero <caseroj@comcast.net>)
Responses Re: What's the best hardver for PostgreSQL 8.1?
List pgsql-performance
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
>

pgsql-performance by date:

Previous
From: Juan Casero
Date:
Subject: Re: MySQL is faster than PgSQL but a large margin in
Next
From: Greg Stark
Date:
Subject: Re: CPU and RAM