SlideShare una empresa de Scribd logo
1 de 20
Descargar para leer sin conexión
ADUBOS TREVO S/A


ANÁLISE DE PERFORMANCE


    UNISYS A14-511




       1
Índice geral

INTRODUÇÃO ................................................................................................................................... 3
SITUAÇÃO ATUAL ........................................................................................................................... 4
   Descrição do Ambiente ................................................................................................................... 4
   Gráficos de utilização ...................................................................................................................... 5
     CPU ............................................................................................................................................ 5
     READYQ.................................................................................................................................... 7
     MEMÓRIA ................................................................................................................................. 7
     I/O - Sistema de Discos .............................................................................................................. 9
   Carga de Trabalho ......................................................................................................................... 13
     Por tipo de carga ....................................................................................................................... 13
CONCLUSÕES ................................................................................................................................. 17
GLOSSÁRIO ..................................................................................................................................... 19




                                                                  2
INTRODUÇÃO - Metodologia Empregada

A Metodologia empregada neste estudo de performance foi a seguinte:

a) entrevistas com o pessoal técnico do cliente, para obtenção de dados sobre a configuração de
hardware e software existente na instalação, e para a seleção dos aplicativos mais importantes que
seriam alvo da monitoração.
b) instalação do software de monitoração (o Viewpoint da Datametrics dos EUA) no mainframe
Unisys e em um micro PC.
c) coleta dos dados de performance, gravando arquivos “tracefile” tanto no host como no PC para
backup, com intervalo de amostragem de 30 segundos.
d) preparação deste relatório de performance, visando responder às seguintes indagações:

 Quanto da capacidade total do equipamento já está sendo utilizada?
 Quais os maiores consumidores individuais de recursos e quanto cada um utiliza?
 Qual o tipo de recurso mais escasso e que limita o aumento da produção da máquina?
 Quais os períodos de tempo mais congestionados e os mais livres?
 O que pode ser feito agora para obter um melhor rendimento do sistema e/ou melhorar o serviço
  prestado aos usuários?


Além de medir o consumo médio dos três tipos de recursos - CPU, memória principal e I/O -
medimos também o consumo por tipo de carga de trabalho (workloads).

Também foram registrados os tempos de resposta dos diversos sistemas online, por programa e por
janela, e o número de transações online de cada um, para permitir comparações com futuras
medições de performance.

A coleta dos dados foi iniciada em 22 de setembro de 2000 às 16 hs, e encerrada em 30 de setembro
às 23:59. Houveram duas pequenas interrupções na monitoração, causadas por paradas do
equipamento e/ou do software de monitoração.




                                            3
SITUAÇÃO ATUAL

Descrição do Ambiente de Hardware e Software (*)

      System Type = A14
      System Serial Number = 666
      MCP Release = 45.189
      Processor List = 4
      I/O Processor List = 0
      Total Memory = 16777216 Words
      Halt Load Unit = 42
      IPAddress = 10.0.0.3
      Subsys LPPATH14 (paths=1) = LP14
      Subsys LPPATH15 (paths=1) = LP15
      Subsys PKPATH42 (paths=1) = PK42
      Subsys SCSIPATH44 (paths=1) = MT44, CD46
      Subsys MTPATH48 (paths=1) = MT48, MT49, MT50
      Subsys PKPATH52 (paths=1) = PK52, PK53, PK54, PK55, PK56
      Subsys MTPATH60 (paths=1) = MT60, MT61, MT62, MT63
      Subsys NPPATH158 (paths=1) = NP158
      Subsys SCPATH600 (paths=1) = SC600
      Subsys SCPATH800 (paths=1) = SC800, SC805, SC806, SC811
      Family DISK = PK42 (Idx=1)
      Family DATACOM = PK52 (Idx=1)
      Family PRODUCAO = PK53 (Idx=1)
      Family TESTE = PK54 (Idx=1)
      Family BANCO = PK55 (Idx=1), PK56 (Idx=2)

(*) Alguns periféricos são reportados pelo sistema mas não existem. Isto não representa um
problema de qualquer espécie.




                                           4
Gráficos de utilização dos recursos do equipamento

CPU

Este gráfico mostra a situação da CPU durante todo o período monitorado. Pode-se notar grandes
picos de utilização, que ocorrem durante o horário diurno pela utilização dos sistemas online
(transacionais). A área verde representa o trabalho útil executado pela CPU para programas da
instalação. A área azul representa CPU disponível, sem trabalho a executar. Há grande
disponibilidade da CPU durante o turno da noite, mas obviamente esta não pode ser usada pelos
sistemas online (para mais definições veja o Glossário no fim deste documento). Olhando este
gráfico poderíamos dizer que o uso de CPU não ultrapassou 90%, mas na verdade isto ocorreu,
como podemos ver adiante. O gráfico fica um pouco distorcido pelo uso das médias de uma hora
necessárias para exibir um período mais longo de tempo.


                                                         CPU - Geral


                                                                          22 Sep 2000 14:00 - 1 Oct 00:00
         100

           90

           80

           70

           60

           50

           40

           30

           20

           10

            0
        Sep22 14:00 Sep23 14:00 Sep24 14:00 Sep25 14:00 Sep26 14:00 Sep27 14:00 Sep28 14:00 Sep29 14:00 Sep30 14:00



                      CPU MCP Pct              CPU User Pct            CPU Idle-True Pct            CPU Idle-False Pct




Os dois próximos gráficos mostram a situação de dois dias típicos em detalhe, analisando turno
online e início do turno batch.




                                                          5
Neste gráfico, os dados são do dia 25/9 (uma segunda-feira), iniciando às 5:30 e terminando no fim
do dia. Neste período a CPU total alcançou um máximo de 97%. Também podemos ver a área rosa,
em cima da azul, que mostra o valor de CPU False Idle. Nestes casos, a CPU estava parada
esperando operações de I/O, normalmente devido à overlay excessivo. Também deve-se notar que o
turno batch coexistiu com o sistema online por algum tempo, após as 19 hs. Isto aumentou a
degradação da performance e tornou os tempos de resposta dos sistemas online 5 vezes maiores (em
média).


                                                        CPU - Geral(Zoom)


                                                                               25 Sep 2000 05:24 - 26 Sep 02:36
              100

               90

               80

               70

               60

               50

               40

               30

               20

               10

                    0
                    05:24   07:24   09:24   11:24       13:24       15:24   17:24     19:24       21:24    23:24     01:24



                            CPU MCP Pct             CPU User Pct             CPU Idle-T rue Pct           CPU Idle-False Pct




Este gráfico mostra o mesmo período, do dia 29/9. Neste caso, a CPU total chegou a 100% diversas
vezes entre as 19:20 e 20 hs. Isto afeta muito o tempo de resposta (TR) dos sistemas online: na
janela CBRW, o TR passou de menos de meio segundo (às 10hs) para mais de 3 segundos (às 20hs).
                                                        CPU - Geral(Zoom)


                                                                              29 Sep 2000 05:24 - 30 Sep 02:36
             100

               90

               80

               70

               60

               50

               40

               30

               20

               10

                   0
                   05:24    07:24   09:24   11:24      13:24        15:24   17:24     19:24       21:24   23:24     01:24



                            CPU MCP Pct             CPU User Pct             CPU Idle-True Pct            CPU Idle-False Pct




                                                                6
READYQ

Os processos ficam esperando atenção da CPU em uma fila chamada ReadyQ. O valor de ReadyQ
entre 3 e 5 é considerado normal. Acima disso já começa a haver degradação da performance.
                                             CPU Queue Depth(Zoom)

                   Tasks waiting for CPU                     22 Sep 2000 16:00 - 1 Oct 00:00                 Scale
              10
                                                                                                               10
               9                                                                                              100

               8

               7

               6

               5

               4

               3

               2

               1

               0
          Sep22 16:00   Sep23 22:00   Sep25 04:00   Sep26 10:00   Sep27 16:00   Sep28 22:00    Sep30 04:00



                                   CPU ReadyQ Depth Avg
                                                     10                                CPU Total Pct
                                                                                                 100




MEMÓRIA

Em termos de memória principal, o sistema analisado está no limite. A memória em uso chega
próxima dos 100% frequentemente.


                                            Memory Utilization

                                           22 Sep 2000 16:00 - 1 Oct 00:00
       100
         90
         80
         70
         60
         50
         40
         30
         20
         10
          0
     Sep22 16:00 ep24 02:00
               S          Sep25 12:00
                                    Sep26 22:00 ep28 08:00
                                              S          Sep29 18:00

                                Mem Save Pct                                     Mem Overlayable Pct
                                Mem Available Pct




                                                         7
Apesar disso, ainda não está havendo grande quantidade de overlays para disco, e a quantidade de
processador usada no gerenciamento da memória (MCP P-BIT) está bem abaixo do limite.

                                Overlays per Second
                 22 Sep 2000 16:00 - 1 Oct 00:00
                  16
                  14
                  12
                  10
                    8
                    6
                    4
                    2
                    0
              Sep22 16:00Sep24 18:00Sep26 20:00Sep28 22:00
                                                    Mem Olays/Sec




                                                  Untitled 34

                                                 22 Sep 2000 16:00 - 1 Oct 20:00
                      6

                      5

                      4

                      3

                      2

                      1

                      0
                  Sep22 16:00Sep24 04:00Sep25 16:00Sep27 04:00Sep28 16:00Sep30 04:00 Oct1 16:00

                                 CPU MCP-Answer Pct                CPU MCP-InvisibleIR Pct
                                 CPU MCP-Pbit Pct




                                                   8
I/O - Sistema de Discos

Utilização de discos por caminho de acesso (canal)

Todas as unidades de discos estão conectadas à CPU através de canais de I/O, chamados na
arquitetura Unisys de Paths (caminhos). Nesta máquina existem dois caminhos para discos, a saber
o PKPATH42 e o PKPATH52 (veja uma representação gráfica na pagina 4). No próximo gráfico
vemos a distribuição de I/Os (operações de I/O por segundo) em cada caminho:

                        I/Os por segundo por canal
                     HIS:22 Sep 2000 16:00 - 1 Oct 00:00
                          Subsys IO/Sec
               80
               70
               60
               50
               40
               30
               20
               10
                 0
           Sep22 16:00 Sep24 18:00 Sep26 20:00 Sep28 22:00

                               PKPATH42                    PKPATH52




O caminho PKPATH42 dá acesso à família DISK, onde reside o sistema operacional MCP/AS.
O outro caminho conecta todas as outras famílias e unidades de disco. Todas estas estão
competindo pelo uso de apenas um canal de I/O, daí a contenção de I/O que se observa no gráfico
abaixo, que mostra o enfileiramento no PKPATH52, praticamente inexistente no PKPATH42:

                 enfileiramento p or canal de I/O
                     HIS: Subsys Q-Depth 1 Oct 00:00
                      22 Sep 2000 16:00 -
                 5
                 4
                 3
                 2
                 1
               0
         Sep22 16:00 Sep24 18:00 Sep26 20:00 Sep28 22:00

                               PKPAT H42                   PKPAT H52




                                           9
Utilização de discos por família

O acesso aos discos por família (I/O por segundo) está assim distribuído:

                           I/Os por segundo por familia
                              22 Sep 2000 16:00 - 1 Oct 00:00
                                   HIS: Fam IO/Sec

                  DISK                                 3

                  BANCO                                                        7,049

                  DATACOM                     1,768

                  PRODUCAO                                         5,391

                  TESTE                           2,408

                                  0     1     2    3       4   5    6      7     8     9   10

Em termos de enfileiramento, a situação é similar:

                            enfileiramento p or familia
                           22 Sep 2000 16:00Q-Depth 00:00
                                  HIS: Fam - 1 Oct Avg

                   DISK               0,033

                   BANCO                      0,327

                   DATACOM            0,036

                   PRODUCAO             0,159

                   TESTE              0,061

                                0,0 0,2 0,4 0,6 0,8 1,0 1,2 1,4 1,6 1,8 2,0



Mas existem picos em determinados horários, onde as famílias Banco e Produção chegaram a
valores entre 2 e 3.




                                                  10
Utilização de discos por unidade

Número de I/O por segundo em cada unidade de disco:
                                      Untitled 36

                           HIS: Unit IO/Sec 22 Sep 2000 16:00 - 1 Oct 00:00

       PK42                                        3


       PK52                              1,768


       PK53                                                           5,391


       PK54                                    2,408


       PK55                                            3,549


       PK56                                            3,496


                          0       1       2        3      4       5       6   7   8




Podemos ver que o número de I/O por segundo está bastante desbalanceado também a nível de
unidade física.




                                              11
As piores unidades, em termos de enfileiramento de acessos a disco, são, pela ordem:

PK55 e PK56 (família Banco) - pior desempenho
PK53 (família Produção)
PK54 (família Teste)



                                                Untitled 37


             HIS: Unit Q-Depth Avg                              22 Sep 2000 16:00 - 1 Oct 00:00
                   77                                      92
                                                   90%
              70%                                  80%
               60%                                 70%
               50%                                 60%
               40%                                 50%
                                                   40%
               30%
                                                   30%
               20%
                                                   20%
               10%      9                          10%
                            4 5 2 1 1     1    1           4 2 1   1 1
                0%                                  0%
                  0,0    0,4   0,8 1,2     1,6 2,0    0,0 0,4 0,8 1,2 1,6 2,0
                                 PK53                            PK54
                    83                                  84
               80%                                 80%
               70%                                 70%
               60%                                 60%
               50%                                 50%
               40%                                 40%
               30%                                 30%
               20%                                 20%
               10%     7                           10%     5 2 2 2
                         2 1 1 2 1        1 1 2                    1   1 1 2
                0%                                  0%
                  0,0 0,4 0,8 1,2          1,6 2,0    0,0 0,4 0,8 1,2 1,6 2,0
                             PK55                                PK56




                                           12
Carga de Trabalho (Workloads)

Por tipo de carga: bancos, remoto, etc.

Neste gráfico podemos ver que os maiores consumidores de memória são os bancos de dados, as
libraries e os programas remotos (Coms).
                                                             Untitled 39


                  HIS: Work Mem Pct                                           22 Sep 2000 16:00 - 1 Oct 04:00
            100

             90

             80

             70

             60

             50

             40

             30

             20

             10

               0
           Sep22 16:00 Sep23 16:00 Sep24 16:00 Sep25 16:00 Sep26 16:00 Sep27 16:00 Sep28 16:00 Sep29 16:00 Sep30 16:00



                            0-Compiler                0-Database                 0-Library                      0-MCS
                            0-Other                   0-Remote                   0-ViewPoint                    0-WFL




Consumo de CPU dos mesmos componentes acima:
                                                          Unt itled 38

                  HIS: Work CPU P ct                      22 Sep 2000 16:00 - 1 Oct 00:00
            80

            70

            60

            50

            40

            30

            20

            10

            0
         Sep22 16:00             Sep24 18:00              Sep26 20:00               Sep28 22:00

                              0-Compiler                           0-Database                          0-Library
                              0-MCS                                0-Other                             0-Remote
                              0-ViewPoint                          0-WFL




                                                            13
Recursos utilizados por programas do COMS

Uso de CPU, por programa Coms

Quanto à CPU, a soma de todos os programas Coms consome ao redor de 15% da CPU, com picos
de até 30%. Os maiores consumidores de CPU nesta classe são:

                                             CPU p or p rograma Coms


                        HIS: COMS CPU Pct                                 22 Sep 2000 16:00 - 1 Oct 00:00




                               CBRWP1 14,1              CTBWP310,3                            EPDWP1     17,7
                               EST WP126,8              FREWP115,5                            IMPREMOT APR
                                                                                                         15,6




Uso de memória, por programa Coms

Estes oito programas consumem de 10% a 15% da memória total do sistema:

                                                   Untitled 36

                                 HIS: COMS Mem Pct           22 Sep 2000 16:00 - 1 Oct 20:00

          ESTWP1                                                                               0,619

          IMPREMOTAPR                                                                         0,604

          ESTWP3                                        0,282

          CTBWP3                               0,198

          CBRWP1                                                                0,492

          CBRWP3                                                      0,403

          NFSWP1                                                                                          0,791

          FREWP1                                                          0,459

                               0,0    0,1    0,2       0,3      0,4           0,5       0,6       0,7   0,8       0,9   1,0




                                                     14
Uso de CPU por transação, por programa Coms

Os oito programas Coms que mais consumem CPU por transação, são (notar o grande campeão
LINC16WP3):
                                              Untitled 37


                           HIS: COMS CPU/Tran                   22 Sep 2000 16:00 - 1 Oct 20:00

         LINC16WP3                                                     4,572                                 8,07


         LINC16WLSS                                            0,469                                         1


         LINC16WP1                                                                                0,89       1


         IMPREMOTAPR                      0,242                                                              1


         CTBWLSS                                0,286                                                        1


         ESTWP3                               0,255                                                          1


         EPDWP1                                             0,418                                            1


         FRE230PR                                0,297                                                       1


                           0      1       2             3       4        5         6         7           8




Número de Transações por Hora, por Janelas do COMS


                                            22 Sep 2000 16:00 - 1 O
 -----------------------------------------------------------------
 Variable Name                          Mean        Min       Max
 -----------------------------------------------------------------
 tran/hora for CBRW                 581,748          0 4501,199
 tran/hora for PRINTING             325,581          0   2255,04
 tran/hora for CTBW                  64,542          0    936,72
 tran/hora for LINC16W                3,737          0    528,72
 tran/hora for CELW                  37,313          0    364,44
 tran/hora for IMPREMOTAW             7,722          0     305,4
 tran/hora for SERW                    0,97          0     57,72




                                              15
Bancos de Dados

Percentual de Memória total do sistema usada pelos principais bancos de dados:
                                          Untitled 40

                         HIS: DMS Mem Pct 22 Sep 2000 16:00 - 1 Oct 00:00
                   35

                   30

                   25

                   20

                   15

                   10

                     5

                     0
                 Sep22 16:00            Sep26 00:00          Sep29 08:00

                               CBR           CTB                 GLOBALDB
                               SER           LINC16DB




Número de overlays por segundo para os principais bancos:


                                          Untitled 41
                         HIS:22 SepOlay/Sec - 1 Oct 00:00
                              DMS 2000 16:00
                   14
                   12
                   10
                     8
                     6
                     4
                     2
                     0
               Sep22 16:00 Sep24 18:00 Sep26 20:00 Sep28 22:00

                                 CBR               CTB          GLOBALDB




                                              16
CONCLUSÕES E SUGESTÕES

Em primeiro lugar vamos responder às perguntas enumeradas no início deste documento.

 Quanto da capacidade total do equipamento já está sendo utilizada?

Aproximadamente metade da capacidade total do equipamento está sendo utilizada.
O problema é que os outros 50% não podem ser utilizados, pois esta disponibilidade ocorre no
horário noturno. Durante o dia, a máquina está sendo totalmente utilizada.

 Quais os maiores consumidores individuais de recursos e quanto cada um utiliza?
Os maiores consumidores de CPU são os programas batch, online, MCS e MCP.
Os programas online (Coms) consomem de 15 a 30% da CPU total (ver pág. 14).
Bancos de dados e libraries somam 50% da memória total em uso.

 Qual o tipo de recurso mais escasso e que limita o aumento da produção da máquina?
Memória principal é com certeza o recurso mais escasso. Qualquer aumento de carga de trabalho
vai determinar um aumento da taxa de overlay para disco, consumindo assim a folga de CPU
eventualmente existente, e aumentando a demanda por acesso a disco, causando piora no tempo de
resposta dos aplicativos online.

 Quais os períodos de tempo mais congestionados e os mais livres?
A máquina está praticamente parada da 00 hs até as 06 hs, diariamente. Os períodos de pico
ocorrem no meio da manhã e no meio da tarde.

 O que pode ser feito agora para obter um melhor rendimento do sistema e/ou melhorar o serviço
  prestado aos usuários?

1. Alterações na Configuração de Hardware:

- Como pode ser visto na figura da página 4, a configuração do subsistema de discos está
completamente desbalanceada. Há dois caminhos de acesso e 6 discos. Em um dos caminhos está
conectado UM disco apenas, e no outro CINCO discos (e nestes estão as famílias mais utilizadas).
Isto provoca congestionamento no acesso aos arquivos, trazendo uma degradação de performance a
todos os sistemas em execução (ver pág. 9).
A não ser que haja uma razão técnica para esta situação, recomendamos solicitar ao fornecedor a
imediata reconfiguração do subsistema de discos.

A redistribuição das famílias de discos também é recomendável. Quando uma família é composta
de vários packs, o MCP se encarrega de distribuir os I/O pelos packs individuais. Assim o
enfileiramento de acessos fica minimizado. No caso específico, isto não ocorre pois todas as
famílias, com exceção de uma, são de um único pack.

Assim, recomendamos:
 UNIR as famílias DATACOM e PRODUÇÃO sob um único nome (PK52 e PK53).
 MOVER os packs PK52 e PK54 para o caminho PKPATH42.




                                           17
2. Alterações de software

- Aproximadamente 5% da memória total em uso pode ser liberada se for possível consolidar os
bancos menores - CTB, SER e GlobalDB, em um só. É um valor importante, levando em conta que
a memória em uso está na casa dos 93-97% durante o período de pico.
- Consolidar o grande número de programas online em um número menor de programas com mais
funções. Deve-se levar em conta o tamanho das transações e evitar consolidar transações com tempo
de resposta muito diferente.

3. Alterações na operação do sistema

Durante uma parte do horário de rede (quando os sistemas podem ser acessados remotamente), os
sistemas batch convivem com os sistemas online. Isto leva à degradação do tempo de resposta dos
aplicativos. Sugerimos transferir toda a execução de jobs batch para após a saída do sistema online,
ou para um horário de pouca utilização da rede, mesmo que isto signifique mais um turno de
operação (deve-se notar que o sistema em uso pelos Supervisores via internet é bastante utilizado
até tarde da noite).
Deve-se enfatizar a restrição existente de não executar jobs batch durante o dia.


CONCLUSÕES

Diversos indicadores positivos levam à conclusão de que esta máquina representa um caso de raro
de ajuste perfeito: ela tem exatamente o poder de processamento necessário para a carga de trabalho
atual - considerando, é claro, que os tempos de resposta estejam satisfatórios, na opinião dos
usuários.
Podemos ver pelos indicadores ReadyQ, Stretch Factor, CPU para o MCP e Overlay Rate que o
equipamento está funcionando sem degradação.
É até possível otimizar a performance, como discutido acima, melhorando o desempenho de alguns
sistemas aplicativos.

No entanto, qualquer aumento da carga de trabalho será prejudicial à qualidade do serviço prestado,
traduzindo-se em aumento do tempo de resposta e atraso na entrega de serviços. Isto porque a
memória está sendo usada acima do limite recomendado, e, se for aumentada, a capacidade de
produção da máquina vai passar a ser limitada pelo subsistema de I/O. O recurso mais disponível, a
CPU, ainda tem alguma folga, que só poderá ser utilizada quando/se for adicionada mais memória.

Em termos de espaço disponível em disco, a soma de todos os segmentos livres não chega a 80% de
um disco, o que é considerado pouco (15%).




                                            18
GLOSSÁRIO

Definição de alguns termos e variáveis usadas neste trabalho. Todas as variáveis estão definidas no
arquivo HELP do Viewpoint.

CPU Total Pct
Total de processador usado durante o período da amostra. É expresso em percentual de CPU. É o
mesmo valor que soma de CPU MCP Pct + CPU User Pct.

CPU MCP Pct
Total de processador usado pelo sistema operacional durante o período da amostra. É expresso em
percentual de CPU. Representa o mesmo valor que a soma de CPU MCP George Pct + CPU MCP -
Answer Pct + CPU MCP - Pbit Pct + CPU MCP - InvisibleIR Pct.

CPU User Pct
Total de processador usado por programas do usuário durante o período da amostra. É expresso em
percentual de CPU.

CPU Idle Pct
Total de processador que não foi usado durante o período da amostra. É expresso em percentual de
CPU. É o mesmo que a soma de CPU Idle - True + CPU Idle-False.

CPU Idle - True Pct
Total de processador realmente disponível durante o período da amostra. É expresso em percentual
de CPU.

CPU Idle - False Pct
Total de processador que parece estar disponível mas não pode ser usado pois iria interferir com
operações de overhead do MCP. É expresso em percentual de CPU.

CPU ReadyQ Depth Avg
Este é o número médio de programas que estão parados esperando o processador central se tornar
disponível para continuar executando. ReadyQ é o nome interno do MCP para a lista de programas
esperando pelo processador.

CPU Stretch Factor
Este é o Stretch Factor para todos os programas executando no sistema. Representa a degradação
média de todos os programas devido à contenção pelo processador central. É calculado pela
fórmula: (Task ReadyQ time + Task CPU time ) / Task CPU time.

Mem Inuse Pct
Este é o total de memória do sistema em uso no fim do período da amostra. É expresso como um
percentual de memória. É o mesmo que Mem Overlayable Pct + Mem Save Pct.


Mem Olay Pct/Sec
Esta é a média do percentual da memória do sistema que é paginada, ou retirada da memória

                                            19
principal, a cada segundo, durante o intervalo da amostra.
Mem Olay/Sec
Esta é a média do número de areas de memória paginadas a cada segundo durante o intervalo da
amostra.

Unit Busy Pct
Este é o total da capacidade de I/O da unidade que foi usado durante o período da amostra. É
expresso como um percentual de I/O.

Fam Q-Depth Avg
Este é o tamanho médio da fila de I/O durante o intervalo da amostra. Este número representa a
contagem média de I/O enfileirados ou esperando para iniciar execução devido a uma unidade ou
canal já em uso.

Unit Q-Depth Avg
Este é o tamanho médio da fila de I/O durante o intervalo da amostra. Este número representa a
contagem média de I/O enfileirados ou esperando para iniciar execução devido a uma unidade já em
uso.

COMS Response Avg
Este é o tempo médio decorrido (elapsed) para todas as trnasações associadas ao programa COMS
durante o intervalo. Para janela DIRETA, este tempo é contado desde que uma mensagem é
colocada na inputqueue do programa até que a primeira mensagem seja enviada. Não é valido para
programas em janela remeta.

COMS Tran/Hora
Número médio de transações para o programa COMS feitas por segundo, durante o intervalo,
multiplicado por 3600.




                                            20

Más contenido relacionado

La actualidad más candente

Apostila de PIC
Apostila de PICApostila de PIC
Apostila de PIC
luizgraf
 
Weg rele-programavel-clic-02-3rd-manual-portugues-br
Weg rele-programavel-clic-02-3rd-manual-portugues-brWeg rele-programavel-clic-02-3rd-manual-portugues-br
Weg rele-programavel-clic-02-3rd-manual-portugues-br
Daniel Dourado
 

La actualidad más candente (16)

Apostila de PIC
Apostila de PICApostila de PIC
Apostila de PIC
 
Foca linux3
Foca linux3Foca linux3
Foca linux3
 
Manual de Usuário Central Modulare i Intelbras - LojaTotalseg.com.br
Manual de Usuário Central Modulare i Intelbras - LojaTotalseg.com.brManual de Usuário Central Modulare i Intelbras - LojaTotalseg.com.br
Manual de Usuário Central Modulare i Intelbras - LojaTotalseg.com.br
 
Apostila linux francisco-araruna
Apostila linux francisco-ararunaApostila linux francisco-araruna
Apostila linux francisco-araruna
 
8051
80518051
8051
 
Apostila de montagem e manutenção de computadores emi mario gurgel
Apostila de montagem e manutenção de computadores emi mario gurgelApostila de montagem e manutenção de computadores emi mario gurgel
Apostila de montagem e manutenção de computadores emi mario gurgel
 
Corolab xq xf_manual pt-v3
Corolab xq xf_manual pt-v3Corolab xq xf_manual pt-v3
Corolab xq xf_manual pt-v3
 
História da criptografia
História da criptografiaHistória da criptografia
História da criptografia
 
ZXP3 - Manual de Usuário Para Impressora
ZXP3 - Manual de Usuário Para ImpressoraZXP3 - Manual de Usuário Para Impressora
ZXP3 - Manual de Usuário Para Impressora
 
Modulare i 01_11
Modulare i 01_11Modulare i 01_11
Modulare i 01_11
 
Clic 02-manual
Clic 02-manualClic 02-manual
Clic 02-manual
 
Manual Técnico do Scanner AVISION AV8050 e AV8350
Manual Técnico do Scanner AVISION AV8050 e AV8350Manual Técnico do Scanner AVISION AV8050 e AV8350
Manual Técnico do Scanner AVISION AV8050 e AV8350
 
Weg rele-programavel-clic-02-3rd-manual-portugues-br
Weg rele-programavel-clic-02-3rd-manual-portugues-brWeg rele-programavel-clic-02-3rd-manual-portugues-br
Weg rele-programavel-clic-02-3rd-manual-portugues-br
 
Installdebian
InstalldebianInstalldebian
Installdebian
 
Foca 1e2
Foca 1e2Foca 1e2
Foca 1e2
 
Manual Técnico do Scanner AVISION AV220C2
Manual Técnico do Scanner AVISION AV220C2Manual Técnico do Scanner AVISION AV220C2
Manual Técnico do Scanner AVISION AV220C2
 

Similar a Relatório de Performance Set00

Projeto de otimização de Performance e Redução de Custos Sistema On-Line
Projeto de otimização de Performance e Redução de Custos Sistema On-LineProjeto de otimização de Performance e Redução de Custos Sistema On-Line
Projeto de otimização de Performance e Redução de Custos Sistema On-Line
Joao Galdino Mello de Souza
 
As percepções Relativas na Application Performance Management, por Gilberto M...
As percepções Relativas na Application Performance Management, por Gilberto M...As percepções Relativas na Application Performance Management, por Gilberto M...
As percepções Relativas na Application Performance Management, por Gilberto M...
Joao Galdino Mello de Souza
 
Plano de Capacidade e Desempenho com perspectiva otimizada para agregar valor...
Plano de Capacidade e Desempenho com perspectiva otimizada para agregar valor...Plano de Capacidade e Desempenho com perspectiva otimizada para agregar valor...
Plano de Capacidade e Desempenho com perspectiva otimizada para agregar valor...
Joao Galdino Mello de Souza
 
Atividade de 1 a 6 da atps
Atividade  de 1 a 6 da atpsAtividade  de 1 a 6 da atps
Atividade de 1 a 6 da atps
Joabe Galvão
 
Arquitetura pentium
Arquitetura pentiumArquitetura pentium
Arquitetura pentium
EMSNEWS
 

Similar a Relatório de Performance Set00 (20)

Troca de contexto segura em sistemas operacionais embarcados utilizando técni...
Troca de contexto segura em sistemas operacionais embarcados utilizando técni...Troca de contexto segura em sistemas operacionais embarcados utilizando técni...
Troca de contexto segura em sistemas operacionais embarcados utilizando técni...
 
Projeto de otimização de Performance e Redução de Custos Sistema On-Line
Projeto de otimização de Performance e Redução de Custos Sistema On-LineProjeto de otimização de Performance e Redução de Custos Sistema On-Line
Projeto de otimização de Performance e Redução de Custos Sistema On-Line
 
Projeto BUS-BUS
Projeto BUS-BUSProjeto BUS-BUS
Projeto BUS-BUS
 
Monitorando sistemas distribuidos
Monitorando sistemas distribuidosMonitorando sistemas distribuidos
Monitorando sistemas distribuidos
 
Performance Tuning de Clusters Plone - PyConBrasil 2 (2006)
Performance Tuning de Clusters Plone - PyConBrasil 2 (2006)Performance Tuning de Clusters Plone - PyConBrasil 2 (2006)
Performance Tuning de Clusters Plone - PyConBrasil 2 (2006)
 
As percepções Relativas na Application Performance Management, por Gilberto M...
As percepções Relativas na Application Performance Management, por Gilberto M...As percepções Relativas na Application Performance Management, por Gilberto M...
As percepções Relativas na Application Performance Management, por Gilberto M...
 
Troca de contexto segura em sistemas operacionais embarcados utilizando de té...
Troca de contexto segura em sistemas operacionais embarcados utilizando de té...Troca de contexto segura em sistemas operacionais embarcados utilizando de té...
Troca de contexto segura em sistemas operacionais embarcados utilizando de té...
 
Aula 2 periféricos
Aula 2   periféricosAula 2   periféricos
Aula 2 periféricos
 
Webinar: Porque o RTOS não faz o que eu quero?
Webinar: Porque o RTOS não faz o que eu quero?Webinar: Porque o RTOS não faz o que eu quero?
Webinar: Porque o RTOS não faz o que eu quero?
 
Manual de sintomas e falhas
Manual de sintomas e falhasManual de sintomas e falhas
Manual de sintomas e falhas
 
Planejamento de Capacidade - Técnicas e Ferramentas
Planejamento de Capacidade - Técnicas e FerramentasPlanejamento de Capacidade - Técnicas e Ferramentas
Planejamento de Capacidade - Técnicas e Ferramentas
 
P spice guia_passo_a_passo
P spice guia_passo_a_passoP spice guia_passo_a_passo
P spice guia_passo_a_passo
 
Plano de Capacidade e Desempenho com perspectiva otimizada para agregar valor...
Plano de Capacidade e Desempenho com perspectiva otimizada para agregar valor...Plano de Capacidade e Desempenho com perspectiva otimizada para agregar valor...
Plano de Capacidade e Desempenho com perspectiva otimizada para agregar valor...
 
Palestra: Computação Paralela na SECOMP 2013 (UNIFEI)
Palestra: Computação Paralela na SECOMP 2013 (UNIFEI)Palestra: Computação Paralela na SECOMP 2013 (UNIFEI)
Palestra: Computação Paralela na SECOMP 2013 (UNIFEI)
 
Atividade de 1 a 6 da atps
Atividade  de 1 a 6 da atpsAtividade  de 1 a 6 da atps
Atividade de 1 a 6 da atps
 
Arquitetura pentium
Arquitetura pentiumArquitetura pentium
Arquitetura pentium
 
Otimização holistica de ambiente computacional
Otimização holistica de ambiente computacionalOtimização holistica de ambiente computacional
Otimização holistica de ambiente computacional
 
Trabalho sobre processadores
Trabalho sobre processadoresTrabalho sobre processadores
Trabalho sobre processadores
 
Tcc sistema de automação residencial baseado em plataforma open hardware e ...
Tcc   sistema de automação residencial baseado em plataforma open hardware e ...Tcc   sistema de automação residencial baseado em plataforma open hardware e ...
Tcc sistema de automação residencial baseado em plataforma open hardware e ...
 
Tudo que você sempre quis saber e sempre teve medo de perguntar, sobre Perfor...
Tudo que você sempre quis saber e sempre teve medo de perguntar, sobre Perfor...Tudo que você sempre quis saber e sempre teve medo de perguntar, sobre Perfor...
Tudo que você sempre quis saber e sempre teve medo de perguntar, sobre Perfor...
 

Más de Ronaldo Radünz (7)

Primavera 2016 release pt br
Primavera 2016 release pt brPrimavera 2016 release pt br
Primavera 2016 release pt br
 
Bitrix24 versão FALL 2015 PT-BR
Bitrix24 versão FALL 2015 PT-BRBitrix24 versão FALL 2015 PT-BR
Bitrix24 versão FALL 2015 PT-BR
 
Bitrix24 cloud-presentation-2015-pt-br
Bitrix24 cloud-presentation-2015-pt-brBitrix24 cloud-presentation-2015-pt-br
Bitrix24 cloud-presentation-2015-pt-br
 
onboarding process flow 1
onboarding process flow 1onboarding process flow 1
onboarding process flow 1
 
swim lane support process example
swim lane support process exampleswim lane support process example
swim lane support process example
 
Best practices monitoring
Best practices  monitoringBest practices  monitoring
Best practices monitoring
 
Environment Monitoring
Environment MonitoringEnvironment Monitoring
Environment Monitoring
 

Relatório de Performance Set00

  • 1. ADUBOS TREVO S/A ANÁLISE DE PERFORMANCE UNISYS A14-511 1
  • 2. Índice geral INTRODUÇÃO ................................................................................................................................... 3 SITUAÇÃO ATUAL ........................................................................................................................... 4 Descrição do Ambiente ................................................................................................................... 4 Gráficos de utilização ...................................................................................................................... 5 CPU ............................................................................................................................................ 5 READYQ.................................................................................................................................... 7 MEMÓRIA ................................................................................................................................. 7 I/O - Sistema de Discos .............................................................................................................. 9 Carga de Trabalho ......................................................................................................................... 13 Por tipo de carga ....................................................................................................................... 13 CONCLUSÕES ................................................................................................................................. 17 GLOSSÁRIO ..................................................................................................................................... 19 2
  • 3. INTRODUÇÃO - Metodologia Empregada A Metodologia empregada neste estudo de performance foi a seguinte: a) entrevistas com o pessoal técnico do cliente, para obtenção de dados sobre a configuração de hardware e software existente na instalação, e para a seleção dos aplicativos mais importantes que seriam alvo da monitoração. b) instalação do software de monitoração (o Viewpoint da Datametrics dos EUA) no mainframe Unisys e em um micro PC. c) coleta dos dados de performance, gravando arquivos “tracefile” tanto no host como no PC para backup, com intervalo de amostragem de 30 segundos. d) preparação deste relatório de performance, visando responder às seguintes indagações:  Quanto da capacidade total do equipamento já está sendo utilizada?  Quais os maiores consumidores individuais de recursos e quanto cada um utiliza?  Qual o tipo de recurso mais escasso e que limita o aumento da produção da máquina?  Quais os períodos de tempo mais congestionados e os mais livres?  O que pode ser feito agora para obter um melhor rendimento do sistema e/ou melhorar o serviço prestado aos usuários? Além de medir o consumo médio dos três tipos de recursos - CPU, memória principal e I/O - medimos também o consumo por tipo de carga de trabalho (workloads). Também foram registrados os tempos de resposta dos diversos sistemas online, por programa e por janela, e o número de transações online de cada um, para permitir comparações com futuras medições de performance. A coleta dos dados foi iniciada em 22 de setembro de 2000 às 16 hs, e encerrada em 30 de setembro às 23:59. Houveram duas pequenas interrupções na monitoração, causadas por paradas do equipamento e/ou do software de monitoração. 3
  • 4. SITUAÇÃO ATUAL Descrição do Ambiente de Hardware e Software (*) System Type = A14 System Serial Number = 666 MCP Release = 45.189 Processor List = 4 I/O Processor List = 0 Total Memory = 16777216 Words Halt Load Unit = 42 IPAddress = 10.0.0.3 Subsys LPPATH14 (paths=1) = LP14 Subsys LPPATH15 (paths=1) = LP15 Subsys PKPATH42 (paths=1) = PK42 Subsys SCSIPATH44 (paths=1) = MT44, CD46 Subsys MTPATH48 (paths=1) = MT48, MT49, MT50 Subsys PKPATH52 (paths=1) = PK52, PK53, PK54, PK55, PK56 Subsys MTPATH60 (paths=1) = MT60, MT61, MT62, MT63 Subsys NPPATH158 (paths=1) = NP158 Subsys SCPATH600 (paths=1) = SC600 Subsys SCPATH800 (paths=1) = SC800, SC805, SC806, SC811 Family DISK = PK42 (Idx=1) Family DATACOM = PK52 (Idx=1) Family PRODUCAO = PK53 (Idx=1) Family TESTE = PK54 (Idx=1) Family BANCO = PK55 (Idx=1), PK56 (Idx=2) (*) Alguns periféricos são reportados pelo sistema mas não existem. Isto não representa um problema de qualquer espécie. 4
  • 5. Gráficos de utilização dos recursos do equipamento CPU Este gráfico mostra a situação da CPU durante todo o período monitorado. Pode-se notar grandes picos de utilização, que ocorrem durante o horário diurno pela utilização dos sistemas online (transacionais). A área verde representa o trabalho útil executado pela CPU para programas da instalação. A área azul representa CPU disponível, sem trabalho a executar. Há grande disponibilidade da CPU durante o turno da noite, mas obviamente esta não pode ser usada pelos sistemas online (para mais definições veja o Glossário no fim deste documento). Olhando este gráfico poderíamos dizer que o uso de CPU não ultrapassou 90%, mas na verdade isto ocorreu, como podemos ver adiante. O gráfico fica um pouco distorcido pelo uso das médias de uma hora necessárias para exibir um período mais longo de tempo. CPU - Geral 22 Sep 2000 14:00 - 1 Oct 00:00 100 90 80 70 60 50 40 30 20 10 0 Sep22 14:00 Sep23 14:00 Sep24 14:00 Sep25 14:00 Sep26 14:00 Sep27 14:00 Sep28 14:00 Sep29 14:00 Sep30 14:00 CPU MCP Pct CPU User Pct CPU Idle-True Pct CPU Idle-False Pct Os dois próximos gráficos mostram a situação de dois dias típicos em detalhe, analisando turno online e início do turno batch. 5
  • 6. Neste gráfico, os dados são do dia 25/9 (uma segunda-feira), iniciando às 5:30 e terminando no fim do dia. Neste período a CPU total alcançou um máximo de 97%. Também podemos ver a área rosa, em cima da azul, que mostra o valor de CPU False Idle. Nestes casos, a CPU estava parada esperando operações de I/O, normalmente devido à overlay excessivo. Também deve-se notar que o turno batch coexistiu com o sistema online por algum tempo, após as 19 hs. Isto aumentou a degradação da performance e tornou os tempos de resposta dos sistemas online 5 vezes maiores (em média). CPU - Geral(Zoom) 25 Sep 2000 05:24 - 26 Sep 02:36 100 90 80 70 60 50 40 30 20 10 0 05:24 07:24 09:24 11:24 13:24 15:24 17:24 19:24 21:24 23:24 01:24 CPU MCP Pct CPU User Pct CPU Idle-T rue Pct CPU Idle-False Pct Este gráfico mostra o mesmo período, do dia 29/9. Neste caso, a CPU total chegou a 100% diversas vezes entre as 19:20 e 20 hs. Isto afeta muito o tempo de resposta (TR) dos sistemas online: na janela CBRW, o TR passou de menos de meio segundo (às 10hs) para mais de 3 segundos (às 20hs). CPU - Geral(Zoom) 29 Sep 2000 05:24 - 30 Sep 02:36 100 90 80 70 60 50 40 30 20 10 0 05:24 07:24 09:24 11:24 13:24 15:24 17:24 19:24 21:24 23:24 01:24 CPU MCP Pct CPU User Pct CPU Idle-True Pct CPU Idle-False Pct 6
  • 7. READYQ Os processos ficam esperando atenção da CPU em uma fila chamada ReadyQ. O valor de ReadyQ entre 3 e 5 é considerado normal. Acima disso já começa a haver degradação da performance. CPU Queue Depth(Zoom) Tasks waiting for CPU 22 Sep 2000 16:00 - 1 Oct 00:00 Scale 10 10 9 100 8 7 6 5 4 3 2 1 0 Sep22 16:00 Sep23 22:00 Sep25 04:00 Sep26 10:00 Sep27 16:00 Sep28 22:00 Sep30 04:00 CPU ReadyQ Depth Avg 10 CPU Total Pct 100 MEMÓRIA Em termos de memória principal, o sistema analisado está no limite. A memória em uso chega próxima dos 100% frequentemente. Memory Utilization 22 Sep 2000 16:00 - 1 Oct 00:00 100 90 80 70 60 50 40 30 20 10 0 Sep22 16:00 ep24 02:00 S Sep25 12:00 Sep26 22:00 ep28 08:00 S Sep29 18:00 Mem Save Pct Mem Overlayable Pct Mem Available Pct 7
  • 8. Apesar disso, ainda não está havendo grande quantidade de overlays para disco, e a quantidade de processador usada no gerenciamento da memória (MCP P-BIT) está bem abaixo do limite. Overlays per Second 22 Sep 2000 16:00 - 1 Oct 00:00 16 14 12 10 8 6 4 2 0 Sep22 16:00Sep24 18:00Sep26 20:00Sep28 22:00 Mem Olays/Sec Untitled 34 22 Sep 2000 16:00 - 1 Oct 20:00 6 5 4 3 2 1 0 Sep22 16:00Sep24 04:00Sep25 16:00Sep27 04:00Sep28 16:00Sep30 04:00 Oct1 16:00 CPU MCP-Answer Pct CPU MCP-InvisibleIR Pct CPU MCP-Pbit Pct 8
  • 9. I/O - Sistema de Discos Utilização de discos por caminho de acesso (canal) Todas as unidades de discos estão conectadas à CPU através de canais de I/O, chamados na arquitetura Unisys de Paths (caminhos). Nesta máquina existem dois caminhos para discos, a saber o PKPATH42 e o PKPATH52 (veja uma representação gráfica na pagina 4). No próximo gráfico vemos a distribuição de I/Os (operações de I/O por segundo) em cada caminho: I/Os por segundo por canal HIS:22 Sep 2000 16:00 - 1 Oct 00:00 Subsys IO/Sec 80 70 60 50 40 30 20 10 0 Sep22 16:00 Sep24 18:00 Sep26 20:00 Sep28 22:00 PKPATH42 PKPATH52 O caminho PKPATH42 dá acesso à família DISK, onde reside o sistema operacional MCP/AS. O outro caminho conecta todas as outras famílias e unidades de disco. Todas estas estão competindo pelo uso de apenas um canal de I/O, daí a contenção de I/O que se observa no gráfico abaixo, que mostra o enfileiramento no PKPATH52, praticamente inexistente no PKPATH42: enfileiramento p or canal de I/O HIS: Subsys Q-Depth 1 Oct 00:00 22 Sep 2000 16:00 - 5 4 3 2 1 0 Sep22 16:00 Sep24 18:00 Sep26 20:00 Sep28 22:00 PKPAT H42 PKPAT H52 9
  • 10. Utilização de discos por família O acesso aos discos por família (I/O por segundo) está assim distribuído: I/Os por segundo por familia 22 Sep 2000 16:00 - 1 Oct 00:00 HIS: Fam IO/Sec DISK 3 BANCO 7,049 DATACOM 1,768 PRODUCAO 5,391 TESTE 2,408 0 1 2 3 4 5 6 7 8 9 10 Em termos de enfileiramento, a situação é similar: enfileiramento p or familia 22 Sep 2000 16:00Q-Depth 00:00 HIS: Fam - 1 Oct Avg DISK 0,033 BANCO 0,327 DATACOM 0,036 PRODUCAO 0,159 TESTE 0,061 0,0 0,2 0,4 0,6 0,8 1,0 1,2 1,4 1,6 1,8 2,0 Mas existem picos em determinados horários, onde as famílias Banco e Produção chegaram a valores entre 2 e 3. 10
  • 11. Utilização de discos por unidade Número de I/O por segundo em cada unidade de disco: Untitled 36 HIS: Unit IO/Sec 22 Sep 2000 16:00 - 1 Oct 00:00 PK42 3 PK52 1,768 PK53 5,391 PK54 2,408 PK55 3,549 PK56 3,496 0 1 2 3 4 5 6 7 8 Podemos ver que o número de I/O por segundo está bastante desbalanceado também a nível de unidade física. 11
  • 12. As piores unidades, em termos de enfileiramento de acessos a disco, são, pela ordem: PK55 e PK56 (família Banco) - pior desempenho PK53 (família Produção) PK54 (família Teste) Untitled 37 HIS: Unit Q-Depth Avg 22 Sep 2000 16:00 - 1 Oct 00:00 77 92 90% 70% 80% 60% 70% 50% 60% 40% 50% 40% 30% 30% 20% 20% 10% 9 10% 4 5 2 1 1 1 1 4 2 1 1 1 0% 0% 0,0 0,4 0,8 1,2 1,6 2,0 0,0 0,4 0,8 1,2 1,6 2,0 PK53 PK54 83 84 80% 80% 70% 70% 60% 60% 50% 50% 40% 40% 30% 30% 20% 20% 10% 7 10% 5 2 2 2 2 1 1 2 1 1 1 2 1 1 1 2 0% 0% 0,0 0,4 0,8 1,2 1,6 2,0 0,0 0,4 0,8 1,2 1,6 2,0 PK55 PK56 12
  • 13. Carga de Trabalho (Workloads) Por tipo de carga: bancos, remoto, etc. Neste gráfico podemos ver que os maiores consumidores de memória são os bancos de dados, as libraries e os programas remotos (Coms). Untitled 39 HIS: Work Mem Pct 22 Sep 2000 16:00 - 1 Oct 04:00 100 90 80 70 60 50 40 30 20 10 0 Sep22 16:00 Sep23 16:00 Sep24 16:00 Sep25 16:00 Sep26 16:00 Sep27 16:00 Sep28 16:00 Sep29 16:00 Sep30 16:00 0-Compiler 0-Database 0-Library 0-MCS 0-Other 0-Remote 0-ViewPoint 0-WFL Consumo de CPU dos mesmos componentes acima: Unt itled 38 HIS: Work CPU P ct 22 Sep 2000 16:00 - 1 Oct 00:00 80 70 60 50 40 30 20 10 0 Sep22 16:00 Sep24 18:00 Sep26 20:00 Sep28 22:00 0-Compiler 0-Database 0-Library 0-MCS 0-Other 0-Remote 0-ViewPoint 0-WFL 13
  • 14. Recursos utilizados por programas do COMS Uso de CPU, por programa Coms Quanto à CPU, a soma de todos os programas Coms consome ao redor de 15% da CPU, com picos de até 30%. Os maiores consumidores de CPU nesta classe são: CPU p or p rograma Coms HIS: COMS CPU Pct 22 Sep 2000 16:00 - 1 Oct 00:00 CBRWP1 14,1 CTBWP310,3 EPDWP1 17,7 EST WP126,8 FREWP115,5 IMPREMOT APR 15,6 Uso de memória, por programa Coms Estes oito programas consumem de 10% a 15% da memória total do sistema: Untitled 36 HIS: COMS Mem Pct 22 Sep 2000 16:00 - 1 Oct 20:00 ESTWP1 0,619 IMPREMOTAPR 0,604 ESTWP3 0,282 CTBWP3 0,198 CBRWP1 0,492 CBRWP3 0,403 NFSWP1 0,791 FREWP1 0,459 0,0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1,0 14
  • 15. Uso de CPU por transação, por programa Coms Os oito programas Coms que mais consumem CPU por transação, são (notar o grande campeão LINC16WP3): Untitled 37 HIS: COMS CPU/Tran 22 Sep 2000 16:00 - 1 Oct 20:00 LINC16WP3 4,572 8,07 LINC16WLSS 0,469 1 LINC16WP1 0,89 1 IMPREMOTAPR 0,242 1 CTBWLSS 0,286 1 ESTWP3 0,255 1 EPDWP1 0,418 1 FRE230PR 0,297 1 0 1 2 3 4 5 6 7 8 Número de Transações por Hora, por Janelas do COMS 22 Sep 2000 16:00 - 1 O ----------------------------------------------------------------- Variable Name Mean Min Max ----------------------------------------------------------------- tran/hora for CBRW 581,748 0 4501,199 tran/hora for PRINTING 325,581 0 2255,04 tran/hora for CTBW 64,542 0 936,72 tran/hora for LINC16W 3,737 0 528,72 tran/hora for CELW 37,313 0 364,44 tran/hora for IMPREMOTAW 7,722 0 305,4 tran/hora for SERW 0,97 0 57,72 15
  • 16. Bancos de Dados Percentual de Memória total do sistema usada pelos principais bancos de dados: Untitled 40 HIS: DMS Mem Pct 22 Sep 2000 16:00 - 1 Oct 00:00 35 30 25 20 15 10 5 0 Sep22 16:00 Sep26 00:00 Sep29 08:00 CBR CTB GLOBALDB SER LINC16DB Número de overlays por segundo para os principais bancos: Untitled 41 HIS:22 SepOlay/Sec - 1 Oct 00:00 DMS 2000 16:00 14 12 10 8 6 4 2 0 Sep22 16:00 Sep24 18:00 Sep26 20:00 Sep28 22:00 CBR CTB GLOBALDB 16
  • 17. CONCLUSÕES E SUGESTÕES Em primeiro lugar vamos responder às perguntas enumeradas no início deste documento.  Quanto da capacidade total do equipamento já está sendo utilizada? Aproximadamente metade da capacidade total do equipamento está sendo utilizada. O problema é que os outros 50% não podem ser utilizados, pois esta disponibilidade ocorre no horário noturno. Durante o dia, a máquina está sendo totalmente utilizada.  Quais os maiores consumidores individuais de recursos e quanto cada um utiliza? Os maiores consumidores de CPU são os programas batch, online, MCS e MCP. Os programas online (Coms) consomem de 15 a 30% da CPU total (ver pág. 14). Bancos de dados e libraries somam 50% da memória total em uso.  Qual o tipo de recurso mais escasso e que limita o aumento da produção da máquina? Memória principal é com certeza o recurso mais escasso. Qualquer aumento de carga de trabalho vai determinar um aumento da taxa de overlay para disco, consumindo assim a folga de CPU eventualmente existente, e aumentando a demanda por acesso a disco, causando piora no tempo de resposta dos aplicativos online.  Quais os períodos de tempo mais congestionados e os mais livres? A máquina está praticamente parada da 00 hs até as 06 hs, diariamente. Os períodos de pico ocorrem no meio da manhã e no meio da tarde.  O que pode ser feito agora para obter um melhor rendimento do sistema e/ou melhorar o serviço prestado aos usuários? 1. Alterações na Configuração de Hardware: - Como pode ser visto na figura da página 4, a configuração do subsistema de discos está completamente desbalanceada. Há dois caminhos de acesso e 6 discos. Em um dos caminhos está conectado UM disco apenas, e no outro CINCO discos (e nestes estão as famílias mais utilizadas). Isto provoca congestionamento no acesso aos arquivos, trazendo uma degradação de performance a todos os sistemas em execução (ver pág. 9). A não ser que haja uma razão técnica para esta situação, recomendamos solicitar ao fornecedor a imediata reconfiguração do subsistema de discos. A redistribuição das famílias de discos também é recomendável. Quando uma família é composta de vários packs, o MCP se encarrega de distribuir os I/O pelos packs individuais. Assim o enfileiramento de acessos fica minimizado. No caso específico, isto não ocorre pois todas as famílias, com exceção de uma, são de um único pack. Assim, recomendamos:  UNIR as famílias DATACOM e PRODUÇÃO sob um único nome (PK52 e PK53).  MOVER os packs PK52 e PK54 para o caminho PKPATH42. 17
  • 18. 2. Alterações de software - Aproximadamente 5% da memória total em uso pode ser liberada se for possível consolidar os bancos menores - CTB, SER e GlobalDB, em um só. É um valor importante, levando em conta que a memória em uso está na casa dos 93-97% durante o período de pico. - Consolidar o grande número de programas online em um número menor de programas com mais funções. Deve-se levar em conta o tamanho das transações e evitar consolidar transações com tempo de resposta muito diferente. 3. Alterações na operação do sistema Durante uma parte do horário de rede (quando os sistemas podem ser acessados remotamente), os sistemas batch convivem com os sistemas online. Isto leva à degradação do tempo de resposta dos aplicativos. Sugerimos transferir toda a execução de jobs batch para após a saída do sistema online, ou para um horário de pouca utilização da rede, mesmo que isto signifique mais um turno de operação (deve-se notar que o sistema em uso pelos Supervisores via internet é bastante utilizado até tarde da noite). Deve-se enfatizar a restrição existente de não executar jobs batch durante o dia. CONCLUSÕES Diversos indicadores positivos levam à conclusão de que esta máquina representa um caso de raro de ajuste perfeito: ela tem exatamente o poder de processamento necessário para a carga de trabalho atual - considerando, é claro, que os tempos de resposta estejam satisfatórios, na opinião dos usuários. Podemos ver pelos indicadores ReadyQ, Stretch Factor, CPU para o MCP e Overlay Rate que o equipamento está funcionando sem degradação. É até possível otimizar a performance, como discutido acima, melhorando o desempenho de alguns sistemas aplicativos. No entanto, qualquer aumento da carga de trabalho será prejudicial à qualidade do serviço prestado, traduzindo-se em aumento do tempo de resposta e atraso na entrega de serviços. Isto porque a memória está sendo usada acima do limite recomendado, e, se for aumentada, a capacidade de produção da máquina vai passar a ser limitada pelo subsistema de I/O. O recurso mais disponível, a CPU, ainda tem alguma folga, que só poderá ser utilizada quando/se for adicionada mais memória. Em termos de espaço disponível em disco, a soma de todos os segmentos livres não chega a 80% de um disco, o que é considerado pouco (15%). 18
  • 19. GLOSSÁRIO Definição de alguns termos e variáveis usadas neste trabalho. Todas as variáveis estão definidas no arquivo HELP do Viewpoint. CPU Total Pct Total de processador usado durante o período da amostra. É expresso em percentual de CPU. É o mesmo valor que soma de CPU MCP Pct + CPU User Pct. CPU MCP Pct Total de processador usado pelo sistema operacional durante o período da amostra. É expresso em percentual de CPU. Representa o mesmo valor que a soma de CPU MCP George Pct + CPU MCP - Answer Pct + CPU MCP - Pbit Pct + CPU MCP - InvisibleIR Pct. CPU User Pct Total de processador usado por programas do usuário durante o período da amostra. É expresso em percentual de CPU. CPU Idle Pct Total de processador que não foi usado durante o período da amostra. É expresso em percentual de CPU. É o mesmo que a soma de CPU Idle - True + CPU Idle-False. CPU Idle - True Pct Total de processador realmente disponível durante o período da amostra. É expresso em percentual de CPU. CPU Idle - False Pct Total de processador que parece estar disponível mas não pode ser usado pois iria interferir com operações de overhead do MCP. É expresso em percentual de CPU. CPU ReadyQ Depth Avg Este é o número médio de programas que estão parados esperando o processador central se tornar disponível para continuar executando. ReadyQ é o nome interno do MCP para a lista de programas esperando pelo processador. CPU Stretch Factor Este é o Stretch Factor para todos os programas executando no sistema. Representa a degradação média de todos os programas devido à contenção pelo processador central. É calculado pela fórmula: (Task ReadyQ time + Task CPU time ) / Task CPU time. Mem Inuse Pct Este é o total de memória do sistema em uso no fim do período da amostra. É expresso como um percentual de memória. É o mesmo que Mem Overlayable Pct + Mem Save Pct. Mem Olay Pct/Sec Esta é a média do percentual da memória do sistema que é paginada, ou retirada da memória 19
  • 20. principal, a cada segundo, durante o intervalo da amostra. Mem Olay/Sec Esta é a média do número de areas de memória paginadas a cada segundo durante o intervalo da amostra. Unit Busy Pct Este é o total da capacidade de I/O da unidade que foi usado durante o período da amostra. É expresso como um percentual de I/O. Fam Q-Depth Avg Este é o tamanho médio da fila de I/O durante o intervalo da amostra. Este número representa a contagem média de I/O enfileirados ou esperando para iniciar execução devido a uma unidade ou canal já em uso. Unit Q-Depth Avg Este é o tamanho médio da fila de I/O durante o intervalo da amostra. Este número representa a contagem média de I/O enfileirados ou esperando para iniciar execução devido a uma unidade já em uso. COMS Response Avg Este é o tempo médio decorrido (elapsed) para todas as trnasações associadas ao programa COMS durante o intervalo. Para janela DIRETA, este tempo é contado desde que uma mensagem é colocada na inputqueue do programa até que a primeira mensagem seja enviada. Não é valido para programas em janela remeta. COMS Tran/Hora Número médio de transações para o programa COMS feitas por segundo, durante o intervalo, multiplicado por 3600. 20