O documento discute três tópicos principais: 1) a importância da medição de desempenho para comparar sistemas, planejar capacidade e cobrar usuários; 2) os diferentes tipos de ferramentas de medição de desempenho, incluindo internas, externas modernas e externas tradicionais; 3) como as ferramentas de medição podem consumir recursos significativos do sistema.

1. Tudo o que sempre você
quis...etc, etc, etc.
 15 de maio de 2018
 CMG São Paulo (Ainda Vivos, Alegria, Alegria...)
 Álvaro Salla

2. Mensagem dos nossos irmãos no MF,
da Turquia
“Bilmiyorum, mevcut
değil ya da önemli
değil".

3. 3
Pronunciamento
Declaro para os devidos fins e para o testemunho
de gerações ainda por vir, que:
"Ao contrário das malidecências propaladas sobre
esta gentil palestra, o palestrante não vai detonar
oralmente (ou por seus slides) nenhum produto
Monitor de Peformance do Mercado, ou o próprio
Mercado... Muito pelo contrário, o seu único
compromisso será com a Verdade..." Mas, ai de
quem tiver medo dela,...
kkkkkkkkk

4. 4
Breaking News... Grafite antigo, arcaico e semi-apagado
nos muros da Escola de Sagres: "Medir é Preciso, Alterar
não..."
Então, o que há de comum entre: Infante D. Henrique,
Heisemberg e Alan Turing?
A resposta seria que tinham desejos parecidos:
Que o astrolábio não altere a altura do astro focado em
relação à linha do horizonte aparente...Desejo atendido...
Que o medir a posição de um elétron no espaço, não altere a
posição desse elétron no tal espaço... Desejo não atendido...
Que um Monitor de Performance ao medir o desempenho
de um sistema computacional não altere o desempenho
desse sistema...Desejo atendido, mas por muito poucos...
Medir...

5. 5
Para que medir o desempenho de um sistema?
Medir aqui quer dizer associar números à Métricas pré-definidas,
e às vezes misteriosas, de maneira que a partir delas possamos:
•Comparar o desempenho de sistemas distintos
•Ter certeza que um projeto de otimização (tuning) está no
caminho certo.
•Resolver problemas de Planejamento de Capacidade.
•Cobrar (charging) do usuário
•Parecer Ciência, e assim por alegre consequência, parecermos
cientistas...

6. 6
CPU Utilization Calculation (old fashion)
CPU UTILIZATION = Total Time Wait Lamp Is Off / Observed Time
Advantages:
Uncertainty Principle does not apply
Very, very cheap
Acceptable margin of error

7. 7
Tipos de Medidores de Desempenho (I)
Internos e oficiais, como aqueles contidos no
binômio z/OS e z Servers como: CPUMF, SAD
Frame, WLM, SRM, System Trace, MasterTrace,
Component Trace e o maior de todos, o SMF.
Há empresas, que quase mais geram e
processam dados de SMF, que aqueles
negociais... hehehehe.
São tantos registros com tantos dados, que a
melhor maneira deles retirarmos informações
valiosas é através da cognitividade, por
exemplo, o Apache/Spark platform.

8. 8
Tipos de Medidores de Desempenho
(II)
Externos e tradicionais como:
•RMF e CMF
•MainView
•Omegamon
•TMON
•Sysview
•outros...

9. 9
Externos, modernos e geralmente tóxico-dependentes de
registros do SMF e com processamento out of box.
Além de monitorar, alguns sugerem e/ou executam
modificações no sistema.
Exemplos:
•MainView Threshold Advisor & Dynamic Threshold
•zRadar
•Intellimagic
•Pivotor
Tipos de Medidores de Desempenho (III)

10. 10
Se diz pelos cantos escuros de TI, com
boca cerrada e lábios apertados, quase em
sussurros, que em média todo o processo
de medida (I + II + III) consome cerca de
XX% da capacidade de processamento de
um sistema.
O que se diz pelos cantos escuros
da TI?

11. 11
Teste de conhecimentos básicos de
Desempenho (I)
O que fazer quando a ocupação de CPU física
está chegando aos 100%, devido um pico de
carga, e as transações de negócio se
movendo pelos corredores da empresa, com
os intestinos ainda com sangue (misturado
com o quimo ainda fresco) nas mãos,
gritando palavrões em Aramaico, o Defined
Capcity capping já foi desativado faz tempo,
e a empresa não tem verba ou contrato para
ativar um CUoD ON?
Dica para a resposta: Por que você quer filmar
a própria morte?

12. 12
Teste de conhecimentos básicos de
Desempenho (II)
O que fazer quando o sistema está absurdamente
lento, as PUs estão com Waiting Time por volta
de 50%? A imensa maioria das tasks está nos
estados de Delay I/O ou Using I/O. O tempo de
I/O Disconnect altíssimo. Os técnicos do
Suporte, já desnorteados (sem norte) se bezutam
com cinzas votivas, mas sem flagelo aparente. E
as transações de negócio com os intestinos etc...
Dica apara a resposta: Para evitar a sua morte
no futuro, você decide morrer agora?
Lembre que tragédia não é morrer, mas não ter
vivido.

13. 13
Mas, porque estamos aqui?
Esta palestra aborda alguns dos milhares de
números produzidos no ato de monitorar,
principalmente aqueles envolvidos na tal
aura de mistério, trevas e pasmo geral...
Portanto, o objetivo desta palestra, a
pertir de agora, é de alumiar tais
dados trazendo o saber que redime.

14. 14
GRS Sysplex replaced GRS Ring topology. The new approach caused that one
GRS is not being informed about other GRS local contention, thus generating
lots of conversation through XCF in order to derive a total contention picture.
To minimize such overhead, z/OS introduced Contention Notification System
(CNS), where the installation selects one GRS to be the CNS, the GRS that is in
real time informed about all happening Sysplex contention. Even though, with
this implementation, there is a lot of consumed resources when GRS API's
GQSCAN and ISGQUERY= QSCAN are issued. The situation is even worse
with the proliferation of performance monitors in an installation.
IBM does recommend that performance monitors should not use such
macros, and instead be a listener of the Event Notification Facility 51 (ENF 51).
However, sure will take time for them to adapt.
Performance problems that can occur mainly on large systems and which are
most problematic to identify can be caused by improper usage of those GRS
services. The services currently invoked too frequent, too generic, or both.
The QSCAN Syndrome

15. 15
Contention Notification
Facility

16. 16
RMF Monitor III introduces a new report with
job oriented GRS (Global Resource
Serialization) statistics report.
It allows to keep track how certain address
spaces are calling the GRS APIs macros to
obtain the contention status of resources,
and requestor of those resources.
The Hard Finger (alcaguete)

17. 17
Mn III Job Oriented Usage report
QSCAN Total - Total # of QScan requests for this AS,
QScan Resct - Average # of resources in contention returned by Qscan for this AS
QScan Time - Average QScan request time, in microseconds, for this AS.

18. 18
É bem sabido que o DB2 exaure a capacidade de uma estrutura de
cache superlotando-a com CIs de suas table spaces, dependendo do
tamanho das table spaces associadas. Veja o pedaço do CF report
abaixo no próximo slide...
Aí a pergunta; Devemos ou não aumentar o tamanho da estrutura?
A resposta: vamos usar uma técnica "Try and Error" com as seguintes
métricas:
M1 = #_of_READs / #_of_WRITEs, larger the better...
M2 = #_WRITEs / #_of_CASTOUTs, larger the better...
Então, aumente o tamanho da estrutura...Se M1 e M2 aumentarem,
então, valeu a pena. Caso contrário, volte ao tamanho anterior...
E que assim seja...
How to size DB2 cache structure
(CF report)

19. 19
CF report covering a DB2 cache
structure

20. 20
Specific I/O performance data
(WKL report)
Several times in my long mainframe life, I was
involved in real performance problems...
In several of them, the CICS transactions were
being penalized along DB2 thread long time
accesses.
I searched the general DASD Activity report
without any I/O DASD bad performance clue.
Suddenly, at WKL report of the DBM1 Service Class,
all the details about only the DB2 DASD I/O
performance...
Bingo!!! A very high I/O Disconnect time was the
explanation...

21. 21
DASD I/O at WKL report

22. 22
Fighting the resources low priority owner effect
 One severe "in any operating system" performance
problem is a low DP task be the exclusive owner of a
very important global resource and be uncapable of
gaining the processor back again to release such
resource.
 There is a natural solution for the problem, that is,
be patient. After a while the major tasks are in wait
state for the resource and finally we have CPU
available to be delivered to the low priority resource,
that releases the ownership. Then, slowly the system
comes back to normal mode. But, in the other hand, iIt
looks like a roller coast. However, this behavior may
affect dramatically the response time of the key
transactions.
 z/OS has several features to minimize such
performance problem.

23. 23
Promotion, the solution
z/OS Promotion means WLM raising temporarily the Dispatching Priority
(DP) of some Dispatchable Units (DUs).
The major reason is that the raised DU has originally a low DP and it is
the owner of a key resource causing contention (queue).
Maybe the reason for not releasing the resource is its low DP, not
allowing such DU to get PU to execute its code and naturally free the
resource.
This Promotion fuction implies in a communication between the specific
resource manager (GRS, IRLM, z/OS Lock manager) and WLM.
The promotion is kept up to:
•The owner DU releases the resource
•A threshold (limit) of PU cycles, or elapsed time is exceeded by the
owner.

24. 24
ERV is the option related to ENQHOLD which is used by GRS
and DB2 for ENQ and latch contention, since long time ago.
DB2 also uses a so called short term ENQHOLD (API
IWMCTCN) for which the promote time is not adjusted by ERV.
MAXPROMOTETIME is the OPT keyword for such function.
DB2 uses such API for long lasting locks. In this case, the
promoted DP is equal to hgihest DP of the DUs being delayed.
Consider that ERV is specified in CPU service units while the
MAXPROMOTETIME is specified in a multiple of 10 seconds.
Interfaces (macros) and thresholds

25. 25
CPU time in seconds that tDUs in this group were running at a promoted
DP, separated by the reason of the promotion:
•BLK CPU time in seconds consumed while the DP of a DU with low importance
was temporarily raised to help blocked workloads. No held resources are
involved. Parameters: BLWLTRPCT (%) , BLWLINTHD
•ENQ CPU time in seconds consumed while the DP was temporarily raised by
enqueue management because the DU held a resource that other DU needed.
Parameter: ERV.
•CRM CPU time in seconds consumed while the DP was temporarily raised by
chronic resource contention management because the DU held a resource that other
DU needed, an example a DB2 lock( não ainda confirmado pela IBM). Parameter:
MAXPROMOTETIME.
•LCK In HiperDispatch mode (????), the CPU time in seconds consumed while the
DP was temporarily raised to shorten the z/OS lock hold time of a local suspend
lock held by a DU.
•SUP CPU time in seconds consumed while the DP for a DU was temporarily raised
by the z/OS supervisor to a higher DP than assigned by WLM.
Description of the Promoted fields at WKL report

26. Promotion fields at WKL report
-TRANSACTIONS- TRANS-TIME HHH.MM.SS.TTT --DASD I/O-- ---SERVICE--- SERVICE TIME ---APPL %--- --PROMOTED--
AVG 9.38 ACTUAL 0 SSCHRT 0.0 IOC 3574 CPU 22.296 CP 0.78 BLK 0.400
MPL 9.38 EXECUTION 0 RESP 0.0 CPU 694029 SRB 0.129 AAPCP 0.00 ENQ 2.300
ENDED 0 QUEUED 0 CONN 0.0 MSO 0 RCT 8.076 IIPCP 0.06 CRM 0.000
END/S 0.00 R/S AFFIN 0 DISC 0.0 SRB 4013 IIT 0.000 LCK 1.875
#SWAPS 2034 INELIGIBLE 0 Q+PEND 0.0 TOT 701616 HST 0.000 AAP N/A SUP 0.002
EXCTD 0 CONVERSION 0 IOSQ 0.0 /SEC 390 AAP N/A IIP 0.91
AVG ENC 0.00 STD DEV 0 IIP 16.413
REM ENC 0.00 ABSRPTN 42
MS ENC 0.00 TRX SERV 42
© Copyright IBM Corp. 2005. All rights reserved.

27. Other WLM Promotion exploiters
© Copyright IBM Corp. 2005. All rights reserved.
IRLM, z/OS Lock manager

28. 28
Shared Pages
Com certeza o conceito de Shared Pages é estranho,
principalmente para quem tem consolidados conceitos de
memória virtual, e de como essa entidade arquitetônica (a
memória virtual) foi implementada no z/OS.
Então, duas pages são shared quando estão associadas a dois
conjuntos de 4K endereços virtuais diferentes (no mesmo ou
em diferentes address spaces), mas compartilham o mesmo
frame de 4 KB na memória real. Criadas pela IEAVSERV macro.
Sharing pages reduz o uso de memória real, a sua
eventual paginação e o uso de Cross Memory.
Seu uso original foi o de permitir que programas A24
pudessem acessar UCBs dinâmicas (acima da linha) sem
gasto adicional de memória real.

29. 29
WKL Report (Storage)

30. Dúvidas?
Até, quem sabe…