Re: Large (8M) cache vs. dual-core CPUs - Mailing list pgsql-performance
From | mark@mark.mielke.cc |
---|---|
Subject | Re: Large (8M) cache vs. dual-core CPUs |
Date | |
Msg-id | 20060426064852.GA16879@mark.mielke.cc Whole thread Raw |
In response to | Re: Large (8M) cache vs. dual-core CPUs (Ron Peacetree <rjpeace@earthlink.net>) |
Responses |
Re: Large (8M) cache vs. dual-core CPUs
|
List | pgsql-performance |
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/
pgsql-performance by date: