There are two distinct system VSE CPU percentage variables provided by the Explore Report Writer.
Article ID: 109011
Updated On: 08-01-2018
Products
Explore Performance Management for z/VSE
Issue/Introduction
There are two distinct system VSE CPU percentage variables provided by the Explore Report Writer.:
Environment
Release:
Component: EXPLVS
Component: EXPLVS
Resolution
There are two distinct system VSE CPU percentage variables provided by the Explore Report Writer:
VSE CPU
%BUSYR – the percentage of the real processor
VSE CPU
%BUSYV – the percentage calculated using the CPU timer.
To illustrate the difference, imagine you have a VM system under which 2 VSE systems are running. Assume that in one minute both VSE systems use 30 cpu seconds, giving a total of 60 seconds for the minute. From a VM perspective the system is 100% busy. The value CPU %BUSYR divides the 30 seconds for each VSE system by elapsed timed
60 seconds) to give 50% busy for both systems, so:
VSEA 50%
VSEB 50%
VM TOTAL
100%
There is however another way of visualising the data.
A value of 50% cpu activity for VSEA may lead someone to think that the virtual machine is only running at half its capacity, and that there are plenty of resources availabe for increased work loads. However we know that VM is running at 100%, so any increase in the workload for VSE will result in CPU contention.
This is why some users of Explore/VSE prefer to use the %BUSYV value. In this case the denominator we use is not the elapsed time, but the cpu timer value, in effect the amount of time that this virtual machine was dispatched by VM. In this case we assume that both VSE systems had the same priority and both were dispatched for
30 seconds each. This gives 30 divided by 30:
VSEA 100%
VSEB 100%
This makes less sense from the overall VM perspective, but indicates more clearly, that the VSE systems are running at full capacity, which may explain any performance bottlenecks. I would not suggest that either %BUSYR or %BUSYV is the one you must use, both are valid, and the one you select will depend on your requirements.
In addition to these system values we also provide the VSE STEP variable VSE STEP %TCPU. This variable uses the %BUSYV method of calculating the CPU percentage. This is why in your report the system VSE %BUSYR looked correct, but the VSE STEP %TCPU for the CICS partition appeared to be too high. Unfortunately we do not have a %BUSYR type version of VSE STEP %TCPU, but as you have seen you can calculate this yourself by dividing the CPU seconds used by the elapsed time.
The calculation of CPU percentage gets more complicated when you have more than 1 cpu processor. With two CPUs for example you could theoretically use 120 cpu seconds in 1 minute. This raises the question of what to use as the denominator when calculating the CPU percentage. If you use wall time (60 seconds) you could see a cpu percentage for your VSE system of 200%. Alternatively you can multiply wall time by number of processors so that the maximum percentage can not exceed 100%. Again both approaches are valid. In the EVSESMCP display which you posted CPU 00 used 17.7%, CPU 01, which was quiesced, used 0%. Explore displayed a total cpu% of 8.8%, because we multiply the denominator by the number of processors to indicate that you are using 8.8% of
the total system.
The report writer also provides a variable class of MCPU that you can use in a multiprocessor environment. You can report on VSE MCPU by cpu processor ID. Whereas the CPU %BUSYR value uses the wall time as the denominator, the MCPU %BUSR value uses the wall time * number of processors as the denominator, so you can choose which representation you prefer.
One idea to keep in mind is that the CPU seconds that we report are an absolute value, whereas the %BUSY values are a way of visualizing that value in a way that lets you know what the value represents in relation to the whole system.
You could also direct the output of the report to a SAM dataset and then ftp the file to another platform for incorporating in a spreadsheet.
Example:
// JOB TRISERV
// DLBL RPTOUT,'EXPRPT.OUTFILE'
// EXEC EXPRPT,SIZE=EXPRPT
INPUT(EVSEFBK)
OUTPUT(RPTOUT,DATA,NOHDR,NODICT)
FROM -0 DAYS AT 01:00:00
TO -0 DAYS AT
05:00:00
EACH 30 MINUTES
TAB DATETIME ,
VSE CPU %BUSYR
AND ,
VSE CPU %BUSYV
AND ,
VSE STEP
%TCPU AND ,
VSE CPU BUSYV
AND ,
VSE
STEP TCPU
END
RUN
/*
/&
The output file contains just the data, the columns are separated by blanks. Unfortunately there is currently no support for formatting this file as a CSV dataset.
As an illustration here is a report I ran. It covers the period when a cpu intensive job was running. I have two processors defined to this VSE system and one was quiesced.
MCPU %BUSYR = MCPU BUSYV / (3600 * 2) - we are using 14% of the total system (where max usage is 100%)
CPU %BUSYR =
CPU BUSYV / 3600 –
we are running 28% CPU busy (where a max usage could be 200%)
MCPU %BUSYV = MCPU BUSYV / (cputimer*2) – we are using
50% CPU (1 of 2 processors fully loaded)
CPU %BUSY = CPU BUSYV
/ (cputimer*2) - This appears to be inconsistent – we should probably have
used CPU BUSYV / cputimer
STEP %TCPU = STEP TCPU / (cputimer * 2)
INPUT(EVSEFBK)
FROM -0 DAYS AT 01:00:00
TO -0 DAYS AT
05:00:00
EACH 1 HOUR
TITLE2 REPORT TO ILLUSTRATE DIFFERENT CPU USE
VARIABLES
HEADER(20,38) ----------- CPU PERCENTAGE
-----------
HEADER(64,22) ------ CPU SECS ------
TAB DATETIME , REPORT 1
VSE MCPU
%BUSYR HDR1(MCPU) HDR2(%BUSYR) AND
,
VSE CPU %BUSYR HDR1(CPU) HDR2(%BUSYR)
AND ,
VSE MCPU
%BUSYV HDR1(MCPU) HDR2(%BUSYV) AND
,
VSE CPU %BUSYV HDR1(CPU) HDR2(%BUSYV)
AND ,
VSE STEP
%TCPU HDR1(STEP) HDR2(%TCPU) AND ,
VSE CPU BUSYV HDR1(CPU) HDR2(BUSYV)
AND ,
VSE
MCPU BUSYV HDR1(MCPU) HDR2(BUSYV) AND ,
VSE
STEP TCPU HDR1(STEP) HDR2(TCPU)
END
RUN
…
FROM
19/07/2018 01.00.00
REPORT 1 PAGE 1
TO
19/07/2018 05.00.00
REPORT TO ILLUSTRATE DIFFERENT CPU USE VARIABLES REPORT DATE 19/07/18 13.45.09
SHIFT NONE
EACH 1
HOUR
PERIOD NONE
----------- CPU PERCENTAGE ----------- ------ CPU SECS ------
MCPU CPU MCPU
CPU STEP CPU
MCPU STEP
DATE TIME
%BUSYR %BUSYR %BUSYV
%BUSYV %TCPU BUSYV
BUSYV TCPU
-------- -----
-------- -------- -------- -------- -------- -------- -------- --------
19/07/18 01.00
14.4 28.9 49.8
49.8 49.8 1039
1039 1039
19/07/18 02.00
14.4 28.8 50.0
50.0 50.0 1037
1037 1037
19/07/18 03.00
14.4 28.8 50.0
50.0 50.0 1036
1036 1036
19/07/18 04.00
13.3 26.6 38.7
38.7 38.6 957.5
957.5 957.5
-------- -----
-------- -------- -------- -------- -------- -------- --------
--------
PERIOD
14.1 28.3 46.7
46.7 46.7 4070
4070 4070
-------- -----
-------- -------- -------- -------- -------- -------- --------
--------
VSE CPU
%BUSYR – the percentage of the real processor
VSE CPU
%BUSYV – the percentage calculated using the CPU timer.
To illustrate the difference, imagine you have a VM system under which 2 VSE systems are running. Assume that in one minute both VSE systems use 30 cpu seconds, giving a total of 60 seconds for the minute. From a VM perspective the system is 100% busy. The value CPU %BUSYR divides the 30 seconds for each VSE system by elapsed timed
60 seconds) to give 50% busy for both systems, so:
VSEA 50%
VSEB 50%
VM TOTAL
100%
There is however another way of visualising the data.
A value of 50% cpu activity for VSEA may lead someone to think that the virtual machine is only running at half its capacity, and that there are plenty of resources availabe for increased work loads. However we know that VM is running at 100%, so any increase in the workload for VSE will result in CPU contention.
This is why some users of Explore/VSE prefer to use the %BUSYV value. In this case the denominator we use is not the elapsed time, but the cpu timer value, in effect the amount of time that this virtual machine was dispatched by VM. In this case we assume that both VSE systems had the same priority and both were dispatched for
30 seconds each. This gives 30 divided by 30:
VSEA 100%
VSEB 100%
This makes less sense from the overall VM perspective, but indicates more clearly, that the VSE systems are running at full capacity, which may explain any performance bottlenecks. I would not suggest that either %BUSYR or %BUSYV is the one you must use, both are valid, and the one you select will depend on your requirements.
In addition to these system values we also provide the VSE STEP variable VSE STEP %TCPU. This variable uses the %BUSYV method of calculating the CPU percentage. This is why in your report the system VSE %BUSYR looked correct, but the VSE STEP %TCPU for the CICS partition appeared to be too high. Unfortunately we do not have a %BUSYR type version of VSE STEP %TCPU, but as you have seen you can calculate this yourself by dividing the CPU seconds used by the elapsed time.
The calculation of CPU percentage gets more complicated when you have more than 1 cpu processor. With two CPUs for example you could theoretically use 120 cpu seconds in 1 minute. This raises the question of what to use as the denominator when calculating the CPU percentage. If you use wall time (60 seconds) you could see a cpu percentage for your VSE system of 200%. Alternatively you can multiply wall time by number of processors so that the maximum percentage can not exceed 100%. Again both approaches are valid. In the EVSESMCP display which you posted CPU 00 used 17.7%, CPU 01, which was quiesced, used 0%. Explore displayed a total cpu% of 8.8%, because we multiply the denominator by the number of processors to indicate that you are using 8.8% of
the total system.
The report writer also provides a variable class of MCPU that you can use in a multiprocessor environment. You can report on VSE MCPU by cpu processor ID. Whereas the CPU %BUSYR value uses the wall time as the denominator, the MCPU %BUSR value uses the wall time * number of processors as the denominator, so you can choose which representation you prefer.
One idea to keep in mind is that the CPU seconds that we report are an absolute value, whereas the %BUSY values are a way of visualizing that value in a way that lets you know what the value represents in relation to the whole system.
You could also direct the output of the report to a SAM dataset and then ftp the file to another platform for incorporating in a spreadsheet.
Example:
// JOB TRISERV
// DLBL RPTOUT,'EXPRPT.OUTFILE'
// EXEC EXPRPT,SIZE=EXPRPT
INPUT(EVSEFBK)
OUTPUT(RPTOUT,DATA,NOHDR,NODICT)
FROM -0 DAYS AT 01:00:00
TO -0 DAYS AT
05:00:00
EACH 30 MINUTES
TAB DATETIME ,
VSE CPU %BUSYR
AND ,
VSE CPU %BUSYV
AND ,
VSE STEP
%TCPU AND ,
VSE CPU BUSYV
AND ,
VSE
STEP TCPU
END
RUN
/*
/&
The output file contains just the data, the columns are separated by blanks. Unfortunately there is currently no support for formatting this file as a CSV dataset.
As an illustration here is a report I ran. It covers the period when a cpu intensive job was running. I have two processors defined to this VSE system and one was quiesced.
MCPU %BUSYR = MCPU BUSYV / (3600 * 2) - we are using 14% of the total system (where max usage is 100%)
CPU %BUSYR =
CPU BUSYV / 3600 –
we are running 28% CPU busy (where a max usage could be 200%)
MCPU %BUSYV = MCPU BUSYV / (cputimer*2) – we are using
50% CPU (1 of 2 processors fully loaded)
CPU %BUSY = CPU BUSYV
/ (cputimer*2) - This appears to be inconsistent – we should probably have
used CPU BUSYV / cputimer
STEP %TCPU = STEP TCPU / (cputimer * 2)
INPUT(EVSEFBK)
FROM -0 DAYS AT 01:00:00
TO -0 DAYS AT
05:00:00
EACH 1 HOUR
TITLE2 REPORT TO ILLUSTRATE DIFFERENT CPU USE
VARIABLES
HEADER(20,38) ----------- CPU PERCENTAGE
-----------
HEADER(64,22) ------ CPU SECS ------
TAB DATETIME , REPORT 1
VSE MCPU
%BUSYR HDR1(MCPU) HDR2(%BUSYR) AND
,
VSE CPU %BUSYR HDR1(CPU) HDR2(%BUSYR)
AND ,
VSE MCPU
%BUSYV HDR1(MCPU) HDR2(%BUSYV) AND
,
VSE CPU %BUSYV HDR1(CPU) HDR2(%BUSYV)
AND ,
VSE STEP
%TCPU HDR1(STEP) HDR2(%TCPU) AND ,
VSE CPU BUSYV HDR1(CPU) HDR2(BUSYV)
AND ,
VSE
MCPU BUSYV HDR1(MCPU) HDR2(BUSYV) AND ,
VSE
STEP TCPU HDR1(STEP) HDR2(TCPU)
END
RUN
…
FROM
19/07/2018 01.00.00
REPORT 1 PAGE 1
TO
19/07/2018 05.00.00
REPORT TO ILLUSTRATE DIFFERENT CPU USE VARIABLES REPORT DATE 19/07/18 13.45.09
SHIFT NONE
EACH 1
HOUR
PERIOD NONE
----------- CPU PERCENTAGE ----------- ------ CPU SECS ------
MCPU CPU MCPU
CPU STEP CPU
MCPU STEP
DATE TIME
%BUSYR %BUSYR %BUSYV
%BUSYV %TCPU BUSYV
BUSYV TCPU
-------- -----
-------- -------- -------- -------- -------- -------- -------- --------
19/07/18 01.00
14.4 28.9 49.8
49.8 49.8 1039
1039 1039
19/07/18 02.00
14.4 28.8 50.0
50.0 50.0 1037
1037 1037
19/07/18 03.00
14.4 28.8 50.0
50.0 50.0 1036
1036 1036
19/07/18 04.00
13.3 26.6 38.7
38.7 38.6 957.5
957.5 957.5
-------- -----
-------- -------- -------- -------- -------- -------- --------
--------
PERIOD
14.1 28.3 46.7
46.7 46.7 4070
4070 4070
-------- -----
-------- -------- -------- -------- -------- -------- --------
--------
Additional Information
If the processor were stopped and inactive we would not consider it when calculating CPU%. A quiesced CPU is however different. If you use the SYSDEF TD,INTQ and SYSDEF TD,THRQ commands to implement CPU balancing then a Quiesced processor may be started when the threshold is reached and then quiesced again when the cpu usage falls below the threshold, so in this case it is always available for work. For this reason the choice was made to include it in the CPU% calculation. Again, I would propose that there is no right or wrong way to do this, and I can see that you would have preferred us not to include quiesced processors when determining CPU%, but we had to make a choice when designing the display. I still believe that the value we display is valid.
Feedback
Yes
No
Powered by
