Re: vfs.hirunningspace on a 3ware 8506
From: Uwe Doering (gemini_at_geminix.org)
Date: 04/21/04
- Previous message: Jim C. Nasby: "Re: vfs.hirunningspace on a 3ware 8506"
- In reply to: Jim C. Nasby: "Re: vfs.hirunningspace on a 3ware 8506"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 21 Apr 2004 20:42:43 +0200 To: freebsd-performance@freebsd.org
Jim C. Nasby wrote:
> On Wed, Apr 21, 2004 at 12:55:07AM +0200, Uwe Doering wrote:
>>Petri Helenius wrote:
>>>Jim C. Nasby wrote:
>>>
>>>>Has anyone done any testing to see what value of vfs.hirunningspace is
>>>>optimal for a 3ware 8506-8?
>>>
>>>Do the 3ware controllers actually care about this value due to the
>>>onboard processing and cache? I thought all writes are satisfied
>>>immediately?
>>
>>The controller itself doesn't care, but the kernel does. With the
>>current implementation, the amount of memory associated with outstanding
>>read requests is subtracted from vfs.hirunningspace. With many
>>concurrent read requests there is no reserve left for write operations,
>>so write performance can suffer substantially.
>>
>>This balancing effect is actually intended in order to give read
>>requests some priority, but in high performance systems with fast,
>>caching raid controllers the default value of said variable is too low
>>and therefore poses a bottleneck.
>
> Unfortunately, it seems the 8500 series only has 1.8MB of cache, so it
> seems like the out-of-the-box setting of 1M may not be too far off.
>
> Is it normally advisable to set vfs.hirunningspace = whatever the
> controller's cache is?
Well, 1.8 MB is not much. The Adaptec controllers we use have 16 MB
buffer space, so I set 'vfs.hirunningspace' to half of that (8 MB).
Basically by the seat of my pants. My thinking was that in cases where
all of this amount was used for write operations the kernel shouldn't be
able to completely flush the controller's buffer in one go. Just a
conservative approach.
In your case, you'll probably get away with picking a value equal to or
even larger than the controller's cache. It might result in a slight
performance penalty, but in case your database server really suffers
from write starvation due to many concurrent read requests, removing
this bottleneck is likely to outweigh that penalty by far.
In any case, unless the effect of tweaking 'vfs.hirunningspace' isn't
outright spectacular you will probably have to run benchmark tests in
order to find the best value for your server.
Uwe
-- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"
- Previous message: Jim C. Nasby: "Re: vfs.hirunningspace on a 3ware 8506"
- In reply to: Jim C. Nasby: "Re: vfs.hirunningspace on a 3ware 8506"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
