Michael Parson wrote:
> In message <44B95637.4030108@gmail.com> , you write:
> 
> <snip>
> 
>> The 'int' numbers don't seem to jump around like 'sys'. I did some 
>> ktruss'ing and found out that the syscall numbers jumping around like 
>> that was actually just caused by 'lcdproc'. 'sys' has returned to what I 
>> can only assume is "normal" levels, but the load average remains high 
>> for a system that's doing nothing IMO:
> 
> Ah.  Now we're getting somewhere.  You're running LCDproc, the util for
> spitting out system stats to a little LCD display?
> 
> http://lcdproc.omnipotent.net/
> 
> How often is it querying your system and updating the display?
> 
> There's an old rule of science, you can't observe something without
> changing it's behavior.  It takes CPU cycles to monitor the system, if
> you're doing the query once a second and pushing those updates to the
> LCD each time, that might be the cause.  It might also just be that
> program having an inefficient method of waiting till it's next run on
> NetBSD.

Well, not really getting anywhere. I think I mentioned in my last e-mail 
(if not, I do apologize! I meant to mention it) that killing lcdproc 
doesn't reduce the load average. It doesn't seem to affect it at all, 
actually. It does make 'sys' drop to much more reasonable levels -- but 
that's about as far as it goes :)

> 
> That's probably due to the program that monitors the UPS checking the
> status of the serial lines it is monitoring.  Might be related, might
> not.  One way to check is to kill off the UPS monitoring for a few
> minutes and see if the load average changes.  Same goes for the lcdproc
> process.

<trying this now>

Nope, doesn't seem to affect the load average either. Still ~1.00

> 
> <snip>
> 
>> I hate to keep comparing to FreeBSD, because, well, NetBSD just isn't 
>> FreeBSD :) But as I said, the load average wasn't constantly ~1.00 on 
>> FreeBSD 4.11.
> 
> That's kinda an old version of FreeBSD, not that it matters. =)

:)

Hmm. I'm sorta out of ideas really. I will try killing off all the 
processes I can, possibly tonight, and see if one of them happens to 
sort it out.

-- 
Mark Cullen <mark.r.cullen@gmail.com>