OT: Unix stutter

[John Esak]

> also he could install "hog" iohog/cpuhog/memhog and top.
> I happen to know he already has my handy dandy vol downloader/installer
> script so here is the exact command:
>
> /setup_gnu hog-1.1 top-3.5beta5
>

I will/may try this..


>
> * All this talk of sar brings to mind sarcheck, which reads sar
> for you and
> would have diagnosed a cach/buffer size vs flush-frequency issue
> and made a
> recommendation to alleviate it (as long as the hardware was just
> plain up to
> the work that needs to get done, which it sounds like it is). And

I apprecdiate all the suggestions you've made. Thanks.

> as soon as
> I say that, I have to say, I beleive that John has olympus tune-up, which
> should be doing more or less the same thing as sarcheck only maybe better
> and of course it just goes ahead and impliments changes rather
> than generate
> a report advising you to do them.

No, I don't believe Olympus Tune-UP ever changes anything at all
"automatically". At least not the way I have it set up. It just makes
reccomendations via email and suggests that you change this resource by this
amount sort of thing.

> * I think the jury is still out on the goodness of this, but it has been
> discussed and at least Bela Lubkin and myself have tried it and
> have not had
> bad results, but not especially good either.(on a very heavily multi-user
> loaded machine in my case. A lot of clerk & report procs for over
> 100 users)
> I am sure john has a caching raid card. Given that, you could try setting
> NAUTOUP and BDFLUSHR both to 0 (cd /etc/conf/cf.d ; ./configure, option 1)
> which totally disabled the OS disk cache, which is fine because the raid
> card has it's own cache and two or more caches in serial with
> each other is
> rarely a benefit. Conversely, you could disable the controllers
> cache in the
> controllers bios. The tamer actions would be to try lowering nbuf
> & friends
> (reduce the wad of data that needs to be flushed every 30 seconds) or
> lowering bdflushr & nautoup (flush more often than 30 seconds so that the
> cache can be very large yet the actual changed data that needs to flush is
> usually small) But it's real easy to make combinations that
> perform very bad
> when trying out different values and playing those two properties against
> each other. And making the change requires rebooting which is hard to do
> often on a busy production machine so you could be stuck with bad settings
> for a whole day each, and the testing cycle is a whole day.

Not being ale to re-boot easily is a general problem especially for things
like this.
Before doing either of the above, though, I would want to verify somehow
that either or the comibination _is_ actually the problem.

>
> * might want to check netstat -i , and netstat -m for suspiciously high
> numbers of errors and streams usage
>
> Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/

I check these reports often.. and there is never any fail ... ever.
Besides, this is the sort of thing that Olympus Tune-Up reports on very well
when there is any kind of a problem, even those which haven't yet caused
fails.

Thanks.

John