From: mark@mark.mielke.cc
To: Ron Peacetree <rjpeace@earthlink.net>
Cc: Scott Marlowe <smarlowe@g2switchworks.com>
Cc: Bill Moran <wmoran@collaborativefusion.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Large (8M) cache vs. dual-core CPUs
Date: Wed, 26 Apr 2006 02:48:53 -0400
Message-ID: <20060426064852.GA16879@mark.mielke.cc> (raw)
In-Reply-To: <8991088.1146020837420.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net>
References: <8991088.1146020837420.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net>
On Tue, Apr 25, 2006 at 11:07:17PM -0400, Ron Peacetree wrote:
> THROUGHPUT is better with DDR2 if and only if there is enough data
> to be fetched in a serial fashion from memory.
> LATENCY however is dependent on the base clock rate of the RAM
> involved. So PC3200, 200MHz x2, is going to actually perform better
> than PC2-5400, 166MHz x4, for almost any memory access pattern
> except those that are highly sequential.
I had forgotten about this. Still, it's not quite as simple as you say.
DDR2 has increased latency, however, it has a greater upper limit,
and when run at the same clock speed (200 Mhz for 200 Mhz), it is
not going to perform worse. Add in double the pre-fetching capability,
and what you get is that most benchmarks show DDR2 5400 as being
slightly faster than DDR 3200.
AMD is switching to DDR2, and I believe that, even after making such a
big deal about latency, and why they wouldn't switch to DDR2, they are
now saying that their on-chip memory controller will be able to access
DDR2 memory (when they support it soon) faster than Intel can, not
having an on-chip memory controller.
You said that DB accesses are random. I'm not so sure. In PostgreSQL,
are not the individual pages often scanned sequentially, especially
because all records are variable length? You don't think PostgreSQL
will regularly read 32 bytes (8 bytes x 4) at a time, in sequence?
Whether for table pages, or index pages - I'm not seeing why the
accesses wouldn't be sequential. You believe PostgreSQL will access
the table pages and index pages randomly on a per-byte basis? What
is the minimum PostgreSQL record size again? Isn't it 32 bytes or
over? :-)
I wish my systems were running the same OS, and I'd run a test for
you. Alas, I don't think comparing Windows to Linux would be valuable.
> A minor point to be noted in addition here is that most DB servers
> under load are limited by their physical IO subsystem, their HDs,
> and not the speed of their RAM.
It seems like a pretty major point to me. :-)
It's why Opteron with RAID kicks ass over HyperTransport.
> All of the above comments about the relative performance of
> different RAM types become insignificant when performance is gated
> by the HD subsystem.
Yes.
Luckily - we don't all have Terrabyte databases... :-)
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mark@mark.mielke.cc, rjpeace@earthlink.net, smarlowe@g2switchworks.com, wmoran@collaborativefusion.com
Subject: Re: Large (8M) cache vs. dual-core CPUs
In-Reply-To: <20060426064852.GA16879@mark.mielke.cc>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox