Ahh..good info. Nothing I can use here, but good info. I say that
because I'm not doing any NFS stuff in this case. What I'm really trying
to do is do lots of sysctl tuning stuffs with regard to memory and disk
IO to maximize the bandwidth for oracle.
On Mon, 2002-07-15 at 15:17, Eric Sandeen wrote:
> On Mon, 2002-07-15 at 14:57, Austin Gonyou wrote:
> >
> > In the following directory in proc, /proc/sys/fs/xfs/, exists the
> > following tuneables, refcache_purge refcache_size . What, if any,
> can I
> > gain by tweaking these on a quad processor P4 Xeon server? I'm using
> > 2.4.19-rc1-aa2 on this box and pushing ~900GB oracle DB. I've got
> 8GB
> > ram also.
>
> Those are for the NFS refcache, which holds references on files
> written
> via NFS, to keep pre-allocation in-place for a while. To quote Steve,
>
> "This prevents xfs from constantly freeing this space and then
> reallocating it on the next write and is a very major performance win
> in
> NFS."
>
> So, the size & purge sysctl values are how big this cache is, and how
> many entries are purged out every time the filesystem syncs (i.e. how
> fast it drains).
>
> If you have a lot of writes coming in at once over NFS making the
> cache
> larger might help. In general you'd probably scale the purge size
> with
> the overall size.
>
> Since it holds things open with pre-allocation, you'll see more disk
> usage while the file is in the NFS refcache. If you have quotas, this
> could impact user quotas. If you have a lot of dirty entries in the
> refcache, umount might take longer, as well.
>
> If you find anything interesting while testing, let us know. :)
>
> -Eric
--
Austin Gonyou <austin@xxxxxxxxxxxxxxx>
Coremetrics, Inc.
signature.asc
Description: This is a digitally signed message part
|