Re: RAID 10 Benchmark with different I/O schedulers
От | Craig James |
---|---|
Тема | Re: RAID 10 Benchmark with different I/O schedulers |
Дата | |
Msg-id | 4820C30A.8010709@emolecules.com обсуждение исходный текст |
Ответ на | Re: RAID 10 Benchmark with different I/O schedulers (Greg Smith <gsmith@gregsmith.com>) |
Ответы |
Re: RAID 10 Benchmark with different I/O schedulers
|
Список | pgsql-performance |
Greg Smith wrote: > On Tue, 6 May 2008, Craig James wrote: > >> I only did two runs of each, which took about 24 minutes. Like the >> first round of tests, the "noise" in the measurements (about 10%) >> exceeds the difference between scheduler-algorithm performance, except >> that "anticipatory" seems to be measurably slower. > > Those are much better results. Any test that says anticipatory is > anything other than useless for database system use with a good > controller I presume is broken, so that's how I know you're in the right > ballpark now but weren't before. > > In order to actually get some useful data out of the noise that is > pgbench, you need a lot more measurements of longer runs. As > perspective, the last time I did something in this area, in order to get > enough data to get a clear picture I ran tests for 12 hours. I'm hoping > to repeat that soon with some more common hardware that gives useful > results I can give out. This data is good enough for what I'm doing. There were reports from non-RAID users that the I/O scheduling could make asmuch as a 4x difference in performance (which makes sense for non-RAID), but these tests show me that three of the fourI/O schedulers are within 10% of each other. Since this matches my intuition of how battery-backed RAID will work, I'msatisfied. If our servers get overloaded to the point where 10% matters, then I need a much more dramatic solution, likefaster machines or more machines. Craig
В списке pgsql-performance по дате отправления: