>> -----Ursprüngliche Nachricht-----
>> Von: Bert Driehuis [mailto:[EMAIL PROTECTED] 
>> Gesendet: Donnerstag, 12. Mai 2005 01:16
>> On Wed, 11 May 2005, Mohr James wrote:
>> 
>> > I am curious about the mechanics of how you actually get 
>> the data. Do
>> > you do the walk once, reading it into an array then parse 
>> the array? 
>> > Or do you do the walk twice, calculating the offset into 
>> the table the 
>> > first time and the do the walk again to get the data?
>> 
>> Normally, one does a walk to get the index-to-name mapping. If 
>> you don't have to consider the possibility that someone adds 
>> or removes 
>> execs before yours in snmpd.conf, you never have to repeat 
>> them. It is 
>> recommended to do request the ExtName together with the data 
>> and verify 
>> that the result matches with what you expect (if they don't, someone 
>> inserted or removed an exec before yours :-)

Thanks. That's what I had figured. It is unlikely that anyone is going to add 
things (yet), but it is definately better to be safe than sorry.

>> > When is the command actually run? It seems to me when the 
>> walk reaches
>> > UCD-SNMP-MIB::extOutput.1, or so it seems.
>> 
>> Yes, it does. This can get quite expensive too. Also, 
>> depending on just 
>> what you exec, you may significantly distort your data 
>> because the extra 
>> code will add load to your system.

Currently I am running vmstat for a couple of cycles an then reading the last  
line (basically what Frank was/is doing). With an average over a few seconds, I 
don't have the sudden spike you get if you run vmstat just once. In my 
experience, that does not generate so much extra load to make a difference.

>> By the way, your subject indicates that you want to 
>> _calculate_ the CPU 
>> load. What you've implemented is an _estimate_ of the CPU 
>> load. The data 
>> you will be rerieving will be wrong unless you retrieve the data at 
>> exactly the interval that the underlying tool you "exec" 
>> reports. You 
>> can only get exact data from the ssCpuRawIdle counter. 
>> Anything else is 
>> a guess, and usually a wrong guess.
>> 
>> Suppose you have a crontab which runs a program that uses 5 
>> CPU seconds 
>> every five minutes. Chances are your exec will show 100% CPU 
>> usage if 
>> you poll during the execution of that script, and 0% if you 
>> poll outside 
>> of that (brief) time period. If you use NTP and you use cron 
>> to do the 
>> polling it is easy to get this to lock-step and show a CPU which is 
>> 99.7% idle as 99.7% full. This is why ssCpuRawIdle and friends were 
>> introduced. You take a start measurement and the time. You 
>> take an end 
>> measurement and the time. You divide the difference by the 
>> elapsed time 
>> and you know the CPU load, instead of having made a (probably wrong) 
>> guess at it.

That is what I have been doing all along, but the values that ssCpuRawIdle are 
showing a very much different than what top or vmstat are showing. Typically 
the difference is about 10%. Granted that could be caused by the load from 
vmstat/top, but it still does seem like a lot. 

What we are trying to do is to get a general idea of the load of the systems 
and nothing exact. We are interesting primarily in how much usage is changing 
over time. For example, we want to see if CPU usage is steadily increasing so 
we can plan to get a faster machine, more memory or whatever. However, the 
lock-step problem is definately something to keep in mind if we start seeing 
continious 100% CPU usage.

>> Hope this helps.

Definately! Thanks!

Regards,

Jim Mohr


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_ids93&alloc_id281&op=click
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to