adrian cockcroft wrote:
Could also be fsflush related, fsflush can indirectly interfere with
streams/network traffic. Bob Sneed told me that the latest patches
include a fix for this problem, or you can increase autoup to reduce
it.
Adrian:
Indeed, the Change Request titled "Interim performance improvements needed
in fsflushd" (CR 4643312) has been implemented in all modern patch levels of
Solaris 8, 9, and 10. The first visible difference of running with
these changes
is that fsflushd now consumes far less CPU. That's a Real Good Thing, since
it runs at SYS priority and has been implicated in all sorts of bizarre
performance
issues in the past!
With these changes, tune_t_fsflushr now defaults to 1 - which, IMO, is the
only value it should ever be, whether or not it is default. When this
wakeup
interval for fsflushd is larger, especially on large-memory systems, the
amplitude of the sawtooth I/O demand fsflushd can create is proportionally
more likely to interfere with other I/O operations. I believe all
Solaris versions
that feature this new default also feature the fsflushd efficiency
enhancements.
Any Solaris version that does not include this default is so far behind
the times
that I'd expect the system to experience various other performance
issues if it
is heavily loaded.
There is still the matter of tuning autoup. Richard McDougall's guidance on
this has long been to make it (max(30, 4*N_GB_RAM)) - but this guidance
pre-dates the fsflushd improvements, and I'm not aware of any updates to
that rule-of-thumb. I believe issues like we had with the old greedy
fsflushd
might now be avoided so long as autoup is maybe 2x-3x the GB of RAM in
the system - but that's just conjecture on my part. The "best" value
should also
depend on the CPU speeds and the amount of RAM fsflush is able to skip over
(such as large pages, for example), plus maybe some consideration of how
fast
the I/O targets can absorb dirty page writes! It's a tunable in need of
a new
rule-of-thumb, I think - or better yet - a new algorithm!
What's "interim" about these changes is that the long-term cure is supposed
to be walking the dirty list rather than scanning as fsflush does. I'm
not up-
to-date on where that effort stands.
Cheers,
-- Bob
Adrian
On 10/27/06, Sean Liu <[EMAIL PROTECTED]> wrote:
By looking at this lockstat output, I suspect there are many
short-lived processes forked-out and died so you can't see them with ps.
Because you are not using solaris 10, You might want to enable
process accounting for a minute during performance hit:
/etc/init.d/acct start; sleep 60; /etc/init.d/acct stop
Then use acctcom to analyze what got run during the minute. That
might surprise you.
This message posted from opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
