Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Getting CPU Utilization in BigIP

I have several questions regarding CPU performance monitoring of the BigIP.

1. What method should be invoked to get CPU utilization on the BigIP?
2. Can the STATISTIC_TM_TOTAL_CYCLES value of the get_global_statistics call be used to determine CPU utilization?
3. Currently when I invoke the get_global_statistics method, the value of STATISTIC_TM_TOTAL_CYCLES is zero. How can that be?

Thanks,
Steven Hotovy
CSG Systems, Inc.
0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
According to the SDK documentation:
STATISTIC_TM_TOTAL_CYCLES - Total CPU cycles spent in traffic management.
STATISTIC_TM_IDLE_CYCLES - CPU cycles spent polling with no traffic.
STATISTIC_TM_SLEEP_CYCLES - CPU cycles yielded to other processes (uniprocessor only).

The actual CPU cycles spent handling traffic is Total - (Idle + Sleep).
These numbers are cumulative since startup. The difference over an interval should be used to get the current load.

The method used to get these statistics is System::Statistics::get_global_statistics

You should get some data back when calling this method, since the stats are cumulative since startup. What do you get for these stats (under TMM cycles) when doing a "bp global show" on the CLI? Do you get anything?

Please note that these statistics only relate to CPU utilization pertaining to traffic management, not the host's CPU utilization. Host's CPU utilization statistics are not available at this time.

Loc

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Is there an ETA on when host CPU stats will be available?

What methods have others used to get the non TMM CPU statistics?

Regards -
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
We had already created an enhancement request (CR 47622) for host CPU statistic support, although it's too late to go into the next release. So it will likely be in the release after that, but unfortunately I can't foresee or tell you the exact date.

Up to this point, there has been no request from anyone to get non-TMM CPU statistics via iControl.

Loc
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
I have run a sequence of get_global_statistics calls and have observed that the STATISTIC_TM_IDLE_CYCLES and STATISTIC_TM_TOTAL_CYCLES do not consistently increase. For example, 5 consecutive values for the STATISTIC_TM_IDLE_CYCLES variable, sampled every 30 seconds, are:

1796202495
3796951039
3976587147
2452193173
2277928730

Since this statistic is supposed to be cumulative, the values should never decrease. Any idea of what the problem might be?


0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
The statistics are 64-bit values and the numbers you are showing look like they are capped at 32-bits. SOAP encoding doesn't support 64-bit numbers natively so we use a structure of two 32-bit numbers and rely on the client application to use those values in whatever local 64-bit representation they can use.

struct ULong64 { 
long high;
long low;
}


You will need to use the high and low 32-bit values to construct a 64-bit number.

Here's some examples on how to do it

Perl:
$value = $Statistic->{"value"}; 
$low = $value->{"low"};
$high = $value->{"high"};
$value64 = ($high<<32)|$low;


C#:
UInt64 build64(VirtualServer.CommonULong64 value) 
{
return ((ulong)value.high<<32)|(ulong)value.low;
}


Hope this helps...

-Joe
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
I am already using that construct in my Perl code. Here is the pertinent snippet from the Perl which calls get_global_statistics:

@statistics = @{$Result->{"statistics"}};
foreach my $stat (@statistics)
{
print " ";
$type = $stat->{"type"};
$value = $stat->{"value"};
$low = $value->{"low"};
$high = $value->{"high"};
$value64 = ($high<<32)|$low;
$time_stamp = $stat->{"time_stamp"};
print "$type : $value64\n";
}

Thanks,
Steve
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
That's odd. This still looks like you are printing out a 32bit number. Can you print out the low and high values as well as the calculated value64 to determine if perl is actually building a correct 64bit number.

-Joe
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Here's the print statement I used to get the low and high values:

printf "%55s %12lu %12lu %12lu\n", $type, $value64, $low, $high;

The results for 5 calls, 30 seconds apart:

STATISTIC_TM_TOTAL_CYCLES 2207039487 2207039487 48770
STATISTIC_TM_TOTAL_CYCLES 943767231 943756860 48779
STATISTIC_TM_TOTAL_CYCLES 1132396479 1132381115 48788
STATISTIC_TM_TOTAL_CYCLES 866303741 866297581 48797
STATISTIC_TM_TOTAL_CYCLES 3267362495 3267325626 48805

Steve
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
This shows that the value in $value64 is the same as the value of the low 32-bit, so the conversion didn't work correctly.
Loc
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Actually, they aren't exactly the same but as I suspected your version of perl is not compiled for 64 bit integer support. The values you are printing out are the 32bit equivalents of the expected values.

I ran your numbers through some C code to make sure that the math was correct and here was the output. The first three values are your numbers, the value-32 is the (high<<32)|low cast as 32-bit unsigned longs and the value-64 is that value using 64-bit math.

=====================
Low: : 2207039487
High : 48770
value64 : 2207039487
value-32 : 2207039487
value-64 : 209467762065407
=====================
Low: : 943756860
High : 48779
value64 : 943767231
value-32 : 943767231
value-64 : 209505153488444
=====================
Low: : 1132381115
High : 48788
value64 : 1132396479
value-32 : 1132396479
value-64 : 209543996818363
=====================
Low: : 866297581
High : 48797
value64 : 866303741
value-32 : 866303741
value-64 : 209582385440493
=====================
Low: : 3267325626
High : 48805
value64 : 3267362495
value-32 : 3267362495
value-64 : 209619146206906


You can test if your build of perl supports 64 bit integers with the info from the Config module:

 use Config; 
print "use64bitint: $Config{use64bitint}\n";
print "longsize: $Config{longsize}\n";
($Config{use64bitint} eq 'define' || $Config{longsize} >= 8) &&
print "quads\n";


So, where does that leave you? You can either re-compile your version of perl to include quad (64-bit) support. Or, I'm sure there is a way to write a routing that takes the high and low values and builds a string representation of the 64 bit integer. Anyone got that routine handy? I don't...

-Joe
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Joe,

Thanks for all the tips. I am able to duplicate your 64-bit results using the Perl BigInt module. This, I'm pretty sure, will allow us to move forward.

Steve
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
That's great. If you want to post some code using BigInt, I'll see if I can get it incorporated into the next version of the SDK (for those without builtin 64-bit support).

-Joe
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Thanks for the tip on using BigInt. I've got correct 64-bit values represented on my perl installation that is built without 64-bit number support by using the following code.

use Math::BigInt; 
...
$value64 = Math::BigInt->new($high)->blsft(32)->bxor($low);


You learn something new everyday...

-Joe
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Thanks for the update! I'll have to dig into this again...

-Joe
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Not easily. XML Schema doesn't support a 64 bit type (at least it didn't when we defined the interfaces.

We contemplated using strings and just passing the values around that way but that has other problems with non-64 bit enabled clients being able to decipher them. Other issues we ran into was the signed/unsigned issue with the high/low values. Java doesn't support an unsigned type (again, at least at the time of designing the interfaces) so when we returned the values as an unsigned long schema type, java threw exception after exception and just wouldn't work.

So, unfortunately, to support every toolkit out there, we are stuck with some limitations. One of them being the low/high 32bit value pairs for the statistics.

Keep in mind that you can always "chunk" your requests to smaller sizes. That won't reduce overall bandwidth usage, but it will make single responses smaller.

-Joe
0