Messages in this thread | | | From | Jeff Moyer <> | Subject | Re: io-scheduler tuning for better read/write ratio | Date | Tue, 23 Jun 2009 09:53:39 -0400 |
| |
Ralf Gross <Ralf-Lists@ralfgross.de> writes:
> Jeff Moyer schrieb: >> Ralf Gross <rg@STZ-Softwaretechnik.com> writes: >> >> > Jeff Moyer schrieb: >> >> Jeff Moyer <jmoyer@redhat.com> writes: >> >> >> >> > Ralf Gross <rg@stz-softwaretechnik.com> writes: >> >> > >> >> >> Casey Dahlin schrieb: >> >> >>> On 06/16/2009 02:40 PM, Ralf Gross wrote: >> >> >>> > David Newall schrieb: >> >> >>> >> Ralf Gross wrote: >> >> >>> >>> write throughput is much higher than the read throughput (40 MB/s >> >> >>> >>> read, 90 MB/s write). >> >> >>> > >> >> >>> > Hm, but I get higher read throughput (160-200 MB/s) if I don't write >> >> >>> > to the device at the same time. >> >> >>> > >> >> >>> > Ralf >> >> >>> >> >> >>> How specifically are you testing? It could depend a lot on the >> >> >>> particular access patterns you're using to test. >> >> >> >> >> >> I did the basic tests with tiobench. The real test is a test backup >> >> >> (bacula) with 2 jobs that create 2 30 GB spool files on that device. >> >> >> The jobs partially write to the device in parallel. Depending which >> >> >> spool file reaches the 30 GB first, one starts reading from that file >> >> >> and writing to tape, while to other is still spooling. >> >> > >> >> > We are missing a lot of details, here. I guess the first thing I'd try >> >> > would be bumping up the max_readahead_kb parameter, since I'm guessing >> >> > that your backup application isn't driving very deep queue depths. If >> >> > that doesn't work, then please provide exact invocations of tiobench >> >> > that reprduce the problem or some blktrace output for your real test. >> >> >> >> Any news, Ralf? >> > >> > sorry for the delay. atm there are large backups running and using the >> > raid device for spooling. So I can't do any tests. >> > >> > Re. read ahead: I tested different settings from 8Kb to 65Kb, this >> > didn't help. >> > >> > I'll do some more tests when the backups are done (3-4 more days). >> >> The default is 128KB, I believe, so it's strange that you would test >> smaller values. ;) I would try something along the lines of 1 or 2 MB. > > Err, yes this should have been MB not KB. > > > $cat /sys/block/sdc/queue/read_ahead_kb > 16384 > $cat /sys/block/sdd/queue/read_ahead_kb > 16384 > > I also tried different values for max_sectors_kb, nr_requests. But the > trend that writes were much faster than reads while there was read and > write load on the device didn't change. > > Changing the deadline parameter writes_starved, write_expire, > read_expire, front_merges or fifo_batch didn't change this behavoir.
OK, bumping up readahead and changing the deadline parameters listed should have give some better results, I would think. Can you give the invocation of tiobench you used so I can try to reproduce this?
Thanks! Jeff
| |