Skip site navigation (1) Skip section navigation (2)

Re: SAN performance mystery

From: Greg Stark <gsstark(at)mit(dot)edu>
To: "Alex Turner" <armtuk(at)gmail(dot)com>
Cc: "Mark Lewis" <mark(dot)lewis(at)mir3(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Brian Hurt" <bhurt(at)janestcapital(dot)com>, "Tim Allen" <tim(at)proximity(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org
Subject: Re: SAN performance mystery
Date: 2006-06-16 11:28:35
Message-ID: 87psh98hlo.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-performance
"Alex Turner" <armtuk(at)gmail(dot)com> writes:

> Given the fact that most SATA drives have only an 8MB cache, and your RAID
> controller should have at least 64MB, I would argue that the system with the
> RAID controller should always be faster.  If it's not, you're getting
> short-changed somewhere, which is typical on linux, because the drivers just
> aren't there for a great many controllers that are out there.

Alternatively Linux is using the 1-4 gigabytes of cache available to it
effectively enough that the 64 megabytes of mostly duplicated cache just isn't
especially helpful...

I never understood why disk caches on the order of megabytes are exciting. Why
should disk manufacturers be any better about cache management than OS
authors?

In the case of RAID 5 this could actually work against you since the RAID
controller can _only_ use its cache to find parity blocks when writing.
Software raid can use all of the OS's disk cache to that end.

-- 
greg


In response to

Responses

pgsql-performance by date

Next:From: Mikael CarneholmDate: 2006-06-16 11:45:09
Subject: Re: SAN performance mystery
Previous:From: Greg StarkDate: 2006-06-16 11:23:26
Subject: Re: Optimizer internals

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group