On Mon, Feb 8, 2010 at 10:49 AM, Josh Berkus <josh@xxxxxxxxxxxx> wrote: > >> That's basically what I've been trying to make clear all along: people >> should keep an open mind, watch what happens, and not make any >> assumptions. There's no clear cut preference for one scheduler or the >> other in all situations. I've seen CFQ do much better, you and Albe >> report situations where the opposite is true. I was just happy to see >> another report of someone running into the same sort of issue I've been >> seeing, because I didn't have very much data to offer about why the >> standard advice of "always use deadline for a database app" might not >> apply to everyone. > > Damn, you would have to make things complicated, eh? > > FWIW, back when deadline was first introduced Mark Wong did some tests > and found Deadline to be the fastest of 4 on DBT2 ... but only by about > 5%. If the read vs. checkpoint analysis is correct, what was happening > is the penalty for checkpoints on deadline was almost wiping out the > advantage for reads, but not quite. > > Those tests were also done on attached storage. > > So, what this suggests is: > reads: deadline > CFQ > writes: CFQ > deadline > attached storage: deadline > CFQ > > Man, we'd need a lot of testing to settle this. I guess that's why > Linux gives us the choice of 4 ... Just to add to the data points. On an 8 core opteron Areca 1680 and a 12 disk RAID-10 for data and 2 disk RAID-1 for WAL, I get noticeably better performance (approximately 15%) and lower load factors (they drop from about 8 to 5 or 6) running noop over the default scheduler, with RHEL 5.4 with the 2.6.18-92.el5 kernel from RHEL 5.2. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
