>>> Douglas Rinckes - SolNet Technologies - Sun NZ ISO wrote
> fsflush comes in specifically when you are doing asynchronous writes, for
> example to a ufs filesystem.
> [snip]
> 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.
Ok, but in the case we had, where fsflush was causing the machine to
totally and utterly _stop_ for half a second, each time the fsflush ran
(due to the amount of pending asyncio) wouldn't raising autoup actually
make the problem worse? It would mean that every 120 seconds, the system
would take an even larger hit...
(note that I don't really feel like testing this out on a live cache -
they mostly work now :)
> 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.
I don't believe that this is the problem. We started seeing the problem
after Stew added the asyncio code into squid - an evening's poking
around showed up the autoup variable, and searching the sunsolve bug
reports showed what it did.
Anthony
-- Anthony Baxter development manager arb@connect.com.au connect.com.au Pty LtdReceived on Mon Mar 30 1998 - 22:01:31 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:39:29 MST