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@xxxxxxxxxxx>
To: pgsql-performance@xxxxxxxxxxxxxx
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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
