Date: Thu, 17 Mar 2011 12:21:14 +0100 From: Ivan Voras <ivoras@freebsd.org> To: Marcus Reid <marcus@blazingdot.com> Cc: freebsd-fs@freebsd.org Subject: Re: gmirror performance Message-ID: <AANLkTi=qdYGduAGAXoqB5wq1KjLYgpozq=MZgSDfh=3D@mail.gmail.com> In-Reply-To: <20110317065720.GA49199@blazingdot.com> References: <4D7F7E33.7050103@yellowspace.net> <ilq8pl$qgf$1@dough.gmane.org> <4D80BFB3.20706@yellowspace.net> <20110317065720.GA49199@blazingdot.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17 March 2011 07:57, Marcus Reid <marcus@blazingdot.com> wrote: > > Wow, that's great. =C2=A0I just almost doubled big sequential read perfor= mance > on one of my machines with this too. =C2=A0The question now is why the de= faults > are the way they are... =C2=A0Does a big vfs.read_max (described as "Clus= ter > read-ahead max block count") pessimize performance in some other way? Note that it will only help sequential reads. If you have a database, e-mail server or any other random IO load, it will not help you one bit. On the other hand, it will also not harm performance in that type of environments. It's an old tunable which has not been properly investigated ever since it was last modified 10 years ago; this and few other obscure file system tunables (hi/lo runningspace, dirhash_maxmem) will be much more sanely tuned for 9.0.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=qdYGduAGAXoqB5wq1KjLYgpozq=MZgSDfh=3D>