Re: [Testperf-general] Re: ExclusiveLock - Mailing list pgsql-hackers
From | Bort, Paul |
---|---|
Subject | Re: [Testperf-general] Re: ExclusiveLock |
Date | |
Msg-id | 735D404BD9E7EB44B9CDFC27FC88809B0582D5FE@mail2.tmwsystems.com Whole thread Raw |
Responses |
Re: [Testperf-general] Re: ExclusiveLock
|
List | pgsql-hackers |
<p><font size="2">> The impression I had was that disk drives no longer pay the slightest</font><br /><font size="2">>attention to interleave specs, because the logical model </font><br /><font size="2">> implied by the</font><br/><font size="2">> concept is too far removed from modern reality (on-disk buffering,</font><br /><font size="2">>variable numbers of sectors per track, transparently remapped bad</font><br /><font size="2">> sectors, yaddayadda).</font><br /><font size="2">> </font><p><font size="2">Entirely true. Interleave was an issue back when thecontroller wasn't fast enough to keep up with 3600 RPM disks, and is now completely obscured from the bus. I don't knowif the ATA spec includes interleave control; I suspect it does not.</font><p><font size="2">> And that's just at thehardware level ... who knows where the </font><br /><font size="2">> filesystem</font><br /><font size="2">> isputting your data, or what the kernel I/O scheduler is doing with</font><br /><font size="2">> your requests :-(</font><br/><font size="2">> </font><br /><font size="2">> Basically I see the TODO item as a blue-sky researchtopic, not</font><br /><font size="2">> something we have any idea how to implement. That doesn't </font><br/><font size="2">> mean it can't</font><br /><font size="2">> be on the TODO list ...</font><br /><font size="2">></font><p><font size="2">I think that if we also take into consideration various hardware and software RAIDconfigurations, this is just too far removed from the database level to be at all practical to throw code at.</font><p><fontsize="2">Perhaps this should be rewritten as a documentation change: recommendations about performancehardware? What we recommend for our highest volume customers (alas, on a proprietary RDBMS, and only x86) is somethinglike this:</font><p><font size="2">- Because drive capacity is so huge now, choose faster drives over larger drives.15K RPM isn't three times faster than 5400, but there is a noticable difference. </font><p><font size="2">- More spindlesreduce delays even further. Mirroring allows reads to happen faster because they can come from either side of themirror, and spanning reduces problems with rotational delays.</font><p><font size="2">- The ideal disk configuration thatwe recommend is a 14 drive chassis with a split backplane. Run each backplane to a separate channel on the controller,and mirror the channels. Use the first drive on each channel for the OS and swap, the second drive for transactionlogs, and the remaining drives spanned (and already mirrored) for data. With a reasonable write cache on the controller,this has proven to be a pretty fast configuration despite a less than ideal engine.</font><p><font size="2">Oneother thought: How does static RAM compare to disk speed nowadays? A 1Gb flash drive might be reasonable forthe WAL if it can keep up. </font>
pgsql-hackers by date: