Getting CPU Utilization in BigIP

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

 

 

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

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?

 

 

 

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

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

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

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

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

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} >= 😎 && 
   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

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