Pasi Kärkkäinen wrote: > > On Tue, Oct 02, 2007 at 09:39:09AM -0400, Ross S. W. Walker wrote: > > Simon Banton wrote: > > > > > > At 12:30 +0200 2/10/07, matthias platzer wrote: > > > > > > > >What I did to work around them was basically switching > to XFS for > > > >everything except / (3ware say their cards are fast, but only on > > > >XFS) AND using very low nr_requests for every blockdev > on the 3ware > > > >card. > > > > > > Hi Matthias, > > > > > > Thanks for this. In my CentOS 5 tests the nr_requests > turned out by > > > default to be 128, rather than the 8192 of CentOS 4.5. > I'll have a go > > > at reducing it still further. > > > > Yes, the nr_requests should be a realistic reflection of what the > > card itself can handle. If too high you will see io_waits stack up > > high. > > > > 64 or 128 are good numbers, rarely have I seen a card that > can handle > > a depth larger then 128 (some older scsi cards did 256 I think). > > > > Hmm.. let's say you have a linux software md-raid array made of sata > drives.. what kind of nr_request values you should use for > that for optimal > performance? > > Thanks! Pasi, Good to hear from you again. I haven't done much testing with software RAID, but after googling around I have found that there truly is no 1 nr_requests setting that fits all pictures. The nr_requests is the maximum number of requests that can be queued before the queue is unplugged and the perfect # of requests queued is a reflection of the workload and the hardware together. Also most system func unplug after each request, so it isn't such a big issue unless the system is under high load. If the default 128 isn't working I would explore hardware or RAID configuration problems first before trying to tweak this setting. The old nr_requests = 8192 was definitely too high. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.