+
+ Well, if you're using async IO on your Solaris squid box, setting autoup
+ to 120 would really, really, really bite. The async IO gets flushed
+ every autoup seconds - once our systems got under load, they'd stop
+ every 30 seconds to flush the async I/O. Setting it to 120 seconds would
+ (it seems to me) be even worse.
+
+ Anthony
+
(i wasn't on this list so i've joined so i can keep an eye on you all. ;-)
fsflush comes in specifically when you are doing asynchronous writes, for
example to a ufs filesystem.
Where synchronous writes are taking place (e.g. to raw or via a ufs filesystem
using directio) fsflush should not be causing much load at all, since it will
have nothing to flush, cos the data is written directly to the disk.
Usual cases where the system can benefit from tuning are where there is a great
deal of local filesystem i/o - so proxy servers sound good.
Remember this is no magic bullet to speed up your filesystems - it just
reduces the amount of CPU time that the fsflush process consumes.
Basically, tune fsflush as follows - watch the amount of CPU the process
takes. If more than about 5% (ie 5 CPU seconds in 100 real seconds) then
add 120 say to the autoup value in /etc/system:
set autoup=120
Give it a boot and see what happens. Note that this is an iterative process
and you might need to do it a few times before you can get the loading down.
One thing to be aware of is that fsflush is also repsonsible for flushing
modified entries from the inode cache to disk. So possibly you need to
look at the inode cache tuning as well. Check out SunWorld Online for
some tuning docs on this, or get Adrian Cockrofts new edition of Sun Performance
and Tuning. I think it is due out shortly.
Hope this helps.
Doug Rinckes
Senior Systems Engineer
SolNet Technologies
Received on Mon Mar 30 1998 - 20:51:42 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:39:29 MST