| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mikael Carneholm | 2006-06-16 11:45:09 | Re: SAN performance mystery |
| Previous Message | Greg Stark | 2006-06-16 11:23:26 | Re: Optimizer internals |