From: | Craig James <craig_james(at)emolecules(dot)com> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: RAID 10 Benchmark with different I/O schedulers |
Date: | 2008-05-06 20:43:54 |
Message-ID: | 4820C30A.8010709@emolecules.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 as much as a 4x difference in performance (which makes sense for non-RAID), but these tests show me that three of the four I/O schedulers are within 10% of each other. Since this matches my intuition of how battery-backed RAID will work, I'm satisfied. If our servers get overloaded to the point where 10% matters, then I need a much more dramatic solution, like faster machines or more machines.
Craig
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Cole | 2008-05-06 21:10:47 | pgfouine - commit details? |
Previous Message | Greg Smith | 2008-05-06 20:35:02 | Re: Possible Redundancy/Performance Solution |