Exemplo de um caso Real Empresa nome fantasia CICLO DIÁRIO Preparado para a empresa 23/10/2005
ÍNDICE RESUMO EXECUTIVO... 3 O BAS - SERVIÇO DE ANÁLISE BATCH... 4 RECOMENDAÇÕES GERAIS... 5 EXPANSÃO DO BUFFER VSAM... 5 TROCA DE ADDRESS SPACE... 5 MUDANÇAS NA SCHEDULAGEM... 5 FITA PARA DASD... 6 ESPERA POR INITIATOR... 6 ANÁLISE DAS CHAMADAS AO DB2... 6 ISOLAMENTO DO DATASET... 6 RECUPERAÇÃO E CPU... 6 MUDANÇA NO PROCESSO... 6 CASE DE UM CICLO BATCH DIÁRIO... 7 CAMINHO CRÍTICO - CICLO TERMINANDO COM O JOB J217922D... 9 RECOMENDAÇÕES DE PERFORMANCE - CICLO TERMINADO COM O JOB J217922D... 10 MELHORA TOTAL PROJETADA - CICLO TERMINANDO COM O JOB J217922D... 47 CICLO BATCH DIÁRIO DESTE CASE... 49 CAMINHO CRÍTICO - CICLO TERMINANDO COM O JOB J111794D... 51 RECOMENDAÇÕES DE PERFORMANCE - CICLO TERMINANDO COM O JOB J111794D... 52 MELHORIA TOTAL PROJETADA - CICLO TERMINANDO COM O JOB J111794D... 66 RESUMO DAS RECOMENDAÇÕES POR AÇÃO - CICLO TERMINANDO COM O JOB J217922D... 68 RESUMO DAS RECOMENDAÇÕES POR AÇÃO - CICLO TERMINANDO COM O JOB J111794D... 70 Caso Prático 2 de 70
Resumo Executivo A ATRI foi contratada para executar o Serviço de Análise Batch - BAS, onde era envolvida a SY1 LPAR. A análise foi preparada utilizando-se os dados coletados de 10 de abril de 2000 até 14 de abril de 2000. A análise foi executada numa empresa privada em um ciclo de um dia e os pontos de término deste ciclo foram identificados pelo pessoal de programação de aplicação da empresa. A análise dos pontos de término resultou na identificação de dois ciclos. O primeiro ciclo terminado com o JOB J217922D. O segundo ciclo terminado com o JOB J111794D. Um resumo do que foi encontrado para cada ponto de término é apresentado a seguir. Ciclo terminando com o JOB J217922D 32% de redução A redução de 2 horas e 26 minutos resultará da Mudança da Schedulagem (1 hora e 25 minutos), Atrasos de Alocação (23 minutos), Reestruturação do JOB (12 minutos), Mudança no Processo (11 minutos), Eliminação de Troca (10 minutos), Bufferização VSAM BLSR (7 minutos), Isolamento de Arquivo (4 minutos), Espera por Initiator (2 minutos) e Fita para Disco (2 minutos). Ciclo Terminando com o JOB J111794D 51% de redução A redução de 2 horas e 16 minutos resultará da Espera por Initiator (54 minutos), Atrasos de Alocações (34 minutos), Mudança do Processo (34 minutos), Reestruturação do JOB (14 minutos) e Eliminação de Troca (10 minutos). Caso Prático 3 de 70
O BAS - Serviço de Análise Batch O Serviço de Análise Batch é um exame minucioso do processamento batch executado no mainframe IBM MVS. Ele faz uso de ferramentas de análises avançadas, que permitem a identificação de oportunidades para melhoria de desempenho no caminho crítico do processamento batch. Todas as melhorias são identificadas com projeções de economia e com o nível relativo de dificuldade. A implantação destas mudanças resultará numa redução da janela batch, permitindo a obtenção dos melhores resultados com a quantidade mínima de tempo. O tempo do pessoal e as operações diárias da empresa foram minimamente impactados. Utilizando-se os dados do JOB coletados no mainframe, o processo de análise é focado nas aplicações na SY1 LPAR. Criando-se um mapa PERT para este projeto de ciclo diário, o qual incluem os tempos de cada task, identificamos o caminho crítico. Este mapa nos leva a identificar os pontos importantes de término. Cada passo no processo que leva aos pontos de término é examinado em detalhe. Tudo isto determina os itens de ação para reduzir o tempo do caminho crítico. Assim que cada recomendação de melhoria é formulada, o efeito projetado no caminho crítico é modelado no mapa do projeto. Desta forma, o efeito final das mudanças resultantes no caminho crítico pode ser previsto com precisão. Caso Prático 4 de 70
Recomendações Gerais Expansão do Buffer VSAM Alguns arquivos VSAM têm executados sobre eles centenas de milhares de EXCPs durante o ciclo batch. Tanto as Técnicas de Bufferização Nativa como a Shared Resources (BLSR) podem diminuir esta quantidade de EXCPs. Uma limitação da bufferização VSAM Nativa é que a mesma só permite a bufferização dos componentes Índices do VSAM para o processamento randômico. A técnica que permite a bufferização tanto do componente Índice como Dados é a BLSR. Uma descrição completa da técnica BLSR pode ser encontrada na publicação IBM GC28-1059-001. http://lsuoe.sncc.lsu.edu/bookmgr-cgi/bookmgr.cmd/shelves OS/390 U2R5.0 MVS Unlicensed Bookshelf IEA1BK51 MVS Batch Local Shared Resources IEA5J600 - GC24.1469.00 A implementação da BLSRI para datasets específicos dentro do caminho crítico poderá reduzir significantemente o ciclo batch. A BLSR pode ser implementada por atualizações nas bibliotecas de JCLs. Troca de Address Space Uma observação chave que afeta todos os ciclos batch é a troca dos JOBs que estão no caminho crítico. Genericamente falando, com os atuais sistemas MVS executando MVS/ESA ou MVA/XA, a troca do serviço batch não é um caminho eficiente de se controlar a utilização dos recursos do sistema, exceto em casos críticos de falta de memória real no sistema.quando os JOBs são swapados out, nenhum trabalho pode ser executado nestas tasks. O Dispatcher do MVS executa um bom trabalho de controlar o uso do processador, utilizando as especificações de prioridades de dispatching locais. Não é necessário, e quase sempre é prejudicial, tentar controlar o acesso ao processador, através de swapping, para um trabalho batch. O processamento de um batch crítico deverá utilizar um grupo especial de performance. Este grupo de performance deverá ser designado para a mais alta prioridade de dispatching que qualquer outro serviço batch. O número de programas permitido para executar neste grupo de performance, Nível de MPL, deverá ser um valor alto bastante para permitir todo o processamento paralelo para usar a vantagem deste recurso de prioritização. Neste CASE que estamos apresentando há por volta de 12 JOBs J216*02D" executando em paralelo. Mudanças na Schedulagem Há momentos específicos no CASE que agora estamos trabalhando nos quais diversos JOBs de diversas divisões de processamento são schedulados para executar serialmente. O schedule desta aplicação deverá ser revisto durantes estes períodos de tempo. A mudança na schedulagem deverá ser feita para permitir que estes JOBs sejam executados em paralelo. Isto irá reduzir o ciclo total do CASE que estamos estudando. Caso Prático 5 de 70
Fita para DASD Há diversos dataset seqüenciais, usados em muitas aplicações, que estão alocados em fita. Estes arquivos são bem pequenos e são lidos várias vezes durante o ciclo batch. Se os arquivos chaves identificados neste documento fossem alocados para DASD ao invés de fita, o tempo do caminho crítico para as aplicações batch poderia ser reduzido. Espera por Initiator Diversos JOBs no caminho crítico esperam por Initiators para poderem começar. Estes JOBs no caminho crítico poderiam ser designados para uma classe de JOB que tenha mais Initiators disponíveis. Uma outra opção poderia ser a de termos mais Initiators disponíveis para todos JOBs batch. Análise das Chamadas ao DB2 Há diversos jobsteps DB2 de longa duração sendo executados. Estes jobsteps consomem poucos recursos no address space do programa. Todo o processamento do banco de dados é executado na região do DB2. A análise do resultado do monitor de performance do DB2 detalhando a atividade no banco de dados deverá ser executada. Exemplos de monitores de performance são o DB2 PM, MainView, ou STROBE. Mudando-se o buffer pool do sistema DB2 poderá se reduzir o tempo de execução destes jobsteps. As modificações também poderão ser feitas no programa SQL para reduzir o consumo de recursos do sistema. Uma análise do comando EXPLAIN para um Plano deverá ser executada. para um DB2 de longa duração. Isolamento do Dataset Datasets chaves são alocados em volumes DASD os quais estão mostrando uma resposta muito grande na fila IOS e tempos e respostas desconectadas. Esta é uma indicação de que outros datasets estão alocados e ativos no mesmo volume DASD. Este isolamento inclui a colocação dos componentes Índice e dados do VSAM em diferentes volumes físicos. Recuperação e CPU Há diversos programas que executam durante o ciclo batch CRIS. A quantidade de CPU consumida no address space do programa é muito alta. Uma análise do uso de CPU por uma ferramenta apropriada poderia identificar as áreas dentro do programa que são muito ineficientes. Mudanças simples no código da aplicação que são fornecidas para o pessoal de aplicação podem recuperar quantidades significantes de ciclos de CPU. Estas mudanças nos códigos poderiam reduzir o tempo do ciclo batch e recuperar recursos de hardware. Mudança no Processo Há diversos jobsteps no caminho crítico do ciclo batch que criam fitas de backup dos arquivos. Os arquivos não são atualizados no ciclo batch. O backup dos arquivos poderia ser criado nos JOBs que executam em paralelo com o processamento do caminho crítico. Modificações detalhadas para mudanças específicas nestas áreas são apresentadas neste documento. Caso Prático 6 de 70
Case de um Ciclo Batch Diário Terminando com o JOB J217922D 12 de abril de 2000 O caminho crítico do Case de um Ciclo Diário no qual estamos trabalhando terminando com o JOB J2117922D começa às 6 horas com a liberação do JOB J277300D no dia 12 de abril de 2000. Ele termina com o JOB J217922D às 1h e 40 m do mesmo dia 12. O tempo total do ciclo é de 7 horas e 40 minutos. Este ciclo forma a base para as observações nesta análise. Tempo base do Ciclo: 7 horas e 40 minutos Segue o mapa da aplicação: Caso Prático 7 de 70
Caso Prático - 8 de 70
Caminho Crítico - Ciclo Terminando com o JOB J217922D O ciclo termina com o JOB J217922D cujo caminho crítico é mostrado em vermelho no mapa da aplicação. Componentes do caminho Crítico Este caminho crítico da aplicação é composto por 18 JOBS. Os JOBS do caminho crítico desta aplicação são listados abaixo juntamente com os tempos de execução a partir do início em 12 de abril: J217922D -- 20 minutos J217662D -- 05 minutos J217969D -- 02 minutos J217930D -- 31 minutos J217921D -- 27 minutos Atraso entre JOB s -- 1 hora e 25 minutos J217610D -- 09 minutos J216610D -- 12 minutos J215610D -- 07 minutos J215150D -- 14 minutos J215A28J -- 30 minutos J215128D -- < 1 minuto J215126D -- < 1 minuto J216Z02D -- 04 minuto J216J02D -- 03 horas e 3 minutos J216002D -- < 1 minuto J216015D -- 14 minutos J217002D -- 05 minutos J277300D -- 09 minutos Total: 7 horas e 40 minutos Caso Prático - 9 de 70
Recomendações de Performance - Ciclo Terminado com o JOB J217922D JOB: J217922D Job Step: F2079401 Mudança do Processo O jobstep F2079401 cria uma cópia backup do dataset V207.DBXXXXXX.F207940. O último acesso a este dataset foi um processo de carga. O OB esperou 1 minuto para a alocação. A espera pode ter sido por falta de unidades de fita. O tempo de execução para o procesamento do backup foi acima de 1 minuto.. Caso Prático - 10 de 70
Recomendação: O processamento de backup executado no step PDVSBKUP poderia ser eliminado. O jobstep 135 deverá ser eliminado do JOB. Se um recovery ou um back out deste arquivo for necessário, então o step F2079401 deverá ser reexecutado. Economia projetada: 2 minutos Caso Prático - 11 de 70
JOB: J217662D (continuação) Reestruturação do JOB O JOB J217662D executa no caminho crítico de um ciclo batch. Do step 31 até o step 54 são executados processos que não deveriam estar no caminho crítico. Estrutura atual do JOB (25 minutos o caminho crítico) J217622D J217922D Estrutura Proposta para o JOB (23 minutos) J217622D Steps 1-31 J217922D J217622D Steps 31-54 Recomendação: os steps de 31 até o 54 deverão ser removidos do caminho crítico do ciclo batch. Estes jobsteps deverão ser transferidos para um JOB diferente. Este novo JOB poderá executar em paralelo com o JOB J217922D. Esta mudança reduzirá o ciclo batch em 2 minutos. Economia Projetada: 2 minutos Caso Prático - 12 de 70
JOB: J217930D Procedure Step: PMUPDATE Isolamento do Arquivo O caminho crítico determina para o PMUDATE que é o tempo de DASD I/O para o volume PRDLXD. Mais de 70% do tempo de I/O foi registrado como tempo DISCONNECT. Uma das causas do alto tempo de DISCONNECT é que diversos arquivos estão ativos em um volume individual. Recomendação: Os componentes Índice e Dados destes datasets deverão ser alocados em volumes físicos DASD separados. Designando-se diferentes STORAGE GROUPS para o componente Índice e Dados a separação pode ser atingida. A separação reduzirá o tempo de DISCONNECT que ocorre durante o processamento da atualização do arquivo. Economia Projetada: 2 minutos Caso Prático - 13 de 70
JOB: J217930D (continuação) Procedure Step: P207962D Isolamento de Arquivo O caminho crítico determina para o jobstep P207962D que o tempo de I/O em DASD estava no volume PRD030. Mais de 66% do tempo estava registrado como DISCONNECT e tempo de IOS Queue. A causa do alto tempo de DISCONNECT como também do tempo de IOS Queue mostra que há diversos datasets ativos neste volume. Os arquivos seqüenciais de entrada e de saída utilizados neste JOB foram ambos alocados neste volume DASD. Recomendação: Os arquivos seqüenciais de entrada e de saída deverão ser alocados para indexar volumes físicos separados de DASD. Designando-se diferentes STORAGE GROUPS para estes datasets esta separação pode ser atingida. A separação reduzirá o DISCONNECT e o tempo IOS Queue que ocorre durante o processamento da atualização do dataset. Economia Projetada: 2 minutos Caso Prático - 14 de 70
JOB: J217921D Reestruturação do JOB O JOB J217921D executa no caminho crítico do ciclo batch. Do step 83 ao step 97 executa processos que não deveriam estar no caminho crítico. É o processamento de manutenção do arquivo V207.D0XXXXXX.ITCDBL00. Este arquivo não é requerido até a execução do JOB J217922D ao final do ciclo. Estrutura Atual do JOB (58 minutos no caminho crítico) J217921D J217930D Estrutura proposta do JOB (48 minutos) J217921D Steps 1-82 J217930D J217921D Steps 83-97 Recomendação: do step 83 ao step 97 todos deverão ser removidos do caminho crítico do ciclo batch. Estes jobsteps deverão ser transferidos para um outro JOB batch. Este novo JOB poderá ser executado em paralelo com o JOB J217930D. Esta mudança reduzirá o ciclo batch em 10 minutos. Economia Projetada: 10 minutos Caso Prático - 15 de 70
JOB: J217921D (continuação) Mudança na Schedulagem O JOB J217921D está schedulado para iniciar às 0 h e 15 min. Durante cada um dos 4 ciclos batch este JOB é iniciado as 0 hora e 15 min em cada madrugada. Recomendação: A schedulagem deverá ser modificada para liberar este JOB depois do término do JOB J217610D. Isto reduzirá o ciclo batch em mais de 1 hora e 25 minutos. Com a mecanização do início deste JOB o tempo do ciclo batch poderá ser recuperado. Este tempo recuperado permitirá a flexibilização na schedulagem do ciclo batch. Economia Projetada: 1 hora e 25 minutos Caso Prático - 16 de 70
JOB: J217610D Atrasos por Alocação O primeiro step do JOB J217610D espera por alocação por mais de 3 minutos. Esta espera poderia ser atribuída à alocação de dispositivo. Um exemplo disto poderia ser a espera por uma unidade de fita ficar disponível. Uma outra causa, poderia ser uma espera por alocação de um dataset individual. O dataset poderia ter sido migrado fora do DASD para a memória de nível 2. O jobstep poderia estar esperando por uma chamada do HSM. Recomendação: Uma identificação do recurso que está causando a espera deve ser completada. O log do JES poderá ter a mensagem se o recurso for um equipamento. Esta mensagem poderia ser por espera de drives de fita. Se o jobstep está esperando por um recall do HSM então deverá haver uma mensagem no log do HSM. Depois que o dataset que estiver causando o recall for identificado ele deverá ser designado para uma classe de gerenciamento que poderia fazer com que causasse uma retenção mais longa do DASD principal. Esta mudança poderia eliminar o atraso por espera de alocação para este jobstep. Economia projetada: 3 minutos Caso Prático - 17 de 70
JOB: J216610D (continuação) Atrasos por alocação O primeiro step do JOB J216610D fica esperando por alocação por mais de 2 minutos. Esta espera pode ser atribuída à alocação de dispositivo. Um exemplo poderia ser a espera por alocação de um drive de fita disponível. Ou poderia ser também uma espera por alocação de um arquivo individual. O arquivo poderia ter sido migrado para fora do DASD para a memória nível 2. O jobstep poderia estar esperando por um recall do arquivo HSM. Recomendação Uma identificação do recurso que está causando a espera deve ser completada. O log do JES conterá a mensagem se o recurso for um equipamento. Esta mensagem poderia ser a espera por unidades de fita magnética disponíveis. Se o jobstep estiver esperando por um recall num arquivo uma mensagem estaria presente no log do HSM. Depois que o dataset que esta causando o recall for identificado ele deverá ser designado para uma classe de gerenciamento que faria uma retenção mais longa do DASD principal. Esta mudança eliminaria a espera por atraso de alocação neste jobstep. Economia Projetada: 2 minutos Caso Prático - 18 de 70
JOB: J215610D (continuação) Atrasos por Alocação O primeiro step do JOB J215610D espera por uma alocação por aproximadamente 3 minutos. Esta espera pode ser atribuída à alocação de dispositivo. Um exemplo o poderia ser uma espera por uma unidade de fita se tornar disponível. Um outro exemplo parecido para esta causa seria a alocação de um arquivo individual. O arquivo poderia ter sido retirado do DASD para memória de nível 2. O jobstep poderia estar esperando por um recall do HSM. Recomendação: Uma identificação do recurso que esta causando a espera necessita ser completada. O log do JES conterá uma mensagem se o recurso for um equipamento. Esta mensagem poderia ser uma espera por uma unidade de fita. Se o jobstep esta esperando por um recall do arquivo uma mensagem estará no log do HSM. Depois de identificado o arquivo que está causando o recall o mesmo deverá ser designado para uma classe de gerenciamento que causará uma retenção mais longa do DASD principal. Esta mudança eliminaria a espera por demora de alocação neste jobstep. Economia Projetada: 3 minutos Caso Prático - 19 de 70
JOB: J215150D Atrasos por Alocação O primeiro step do JOB J215150D fica em espera por alocação por mais de 4 minutos. Esta espera pode ser atribuída por alocação de dispositivo. Um exemplo poderia ser a espera por uma unidade de fita se tornar disponível. Outra situação parecida que causaria a espera poderia ser a alocação de um arquivo individual. O dataset poderia ter sido migrado do DASD para a memória nível 2. O jobstep poderia estar esperando por um recall do arquivo HSM. Recomendação: A identificação do recurso que está causando a espera necessita ser completada. No log do JES poderá ter uma mensagem se o recurso for equipamento. Isto poderia ser uma espera por uma mensagem de drive de fita. Se o jobstep estiver esperando por um recall de arquivo uma mensagem poderá ter sido criada no log do HSM. Após o dataset que causou o recall ser identificado ele deverá ser designado para uma classe de mensagem que cause uma retenção mais demorada do DASD principal. Esta mudança eliminaria a espera pelo atraso da alocação para este jobstep. Economia Projetada: 3 minutos Caso Prático - 20 de 70
JOB: J215150D (continuação) Espera por Initiator O JOB J215150D está no caminho crítico do ciclo batch. Este JOB esperou por mais de 2 minutos para um Initiator se tornar disponível. Recomendação:: O JOB A215150D deverá iniciar a execução depois de terminada a série de JOBS J215A28x. Esta mudança irá encurtar o ciclo batch em 2 minutos. Economia Projetada: 2 minutos Caso Prático - 21 de 70
JOB: J215150D (continuação) Job Step: SORT1, SORT2 e SORT3 Fita para Disco Os jobsteps SORT1, SORT2 e SORT3 criam arquivos em fita. Estes arquivos são menores que a capacidade de uma fita (cartucho) inteira. Três fitas (cartuchos) inteiras e três operações de montagem de fita foram requeridas para este processamento. Recomendação: Este processamento está no caminho crítico do processamento batch. Alocando-se os arquivos em disco será removido o overhead de ter estes arquivos em fita magnética neste processamento batch. Tendo estes arquivos gerenciados pelo HSM a capacidade das fitas também seria recuperada por outros serviços. Economia Projetada: 2 minutos Caso Prático - 22 de 70
JOB: J215J28D Atrasos na Alocação O primeiro step do JOB J215J28D espera por uma alocação por mais de 11 minutos. Esta espera poderia ser atribuída por alocação de dispositivo. Um exemplo poderia ser a espera por uma unidade de fita magnética se tornar disponível. Uma outra causa parecida poderia ser a espera por alocação de um arquivo individual. O arquivo poderia ter sido migrado do DASD para a memória nível 2. O jobstep poderia estar esperando por um recall do dataset pelo HSM. Recomendação: A identificação do recurso que está causando a espera deverá ser completada. O log do JES conterá uma mensagem se o recurso causador for equipamento. O motivo poderia ser uma mensagem por espera de unidades de fitas disponíveis. Se o jobstep estivesse esperando por um recall de dataset a mensagem respectiva estaria no log do HSM. Após o dataset que causou o recall ter sido identificado ele deverá ser designado para uma classe de gerenciamento a qual poderia causar uma retenção mais longa do DASD principal. Esta mudança eliminaria a espera por atraso de alocação para este jobstep. Economia Projetada: 12 minutos Caso Prático - 23 de 70
JOB: J125I28D Espera por Initiator O JOB J125I28D está no caminho crítico do ciclo batch. Este JOB esperou aproximadamente por 6 minutos para um Initiator se tornar disponível. Recomendação: O JOB J216I28D deverá iniciar sua execução após o término do JOB J216Z02D. Economia Projetada: É necessário manter este JOB fora do caminho crítico do ciclo batch Caso Prático - 24 de 70
JOBs: J215A28D, J215B28D, J215C28D, J215D28D, J215E28D, J215F28D, J215G28D, J215H28D, J215I28D e J215J28D Job Step: P205103D Bufferização VSAM BLSR Este jobstep executa um número grande de EXCPs em um arquivo VSAM. Os arquivos VSAM são listados abaixo. Estes arquivos são compartilhados por este programa em todos os JOBs listados acima. No ciclo batch há mais de 500,000 milhões de EXCPs executados nestes arquivos. O tamanho dos arquivos é 4 Mega Recomendação: Nas recomendações gerais existe a referência à facilidade BLSR. Nós recomendamos um total combinado de buffers no mínimo de 1,250 BLSR (10 megabytes) e 1,000 BLSR buffers de Índice (2 megabytes) para estes componentes VSAM. Até que o BLSR seja aplicado em sua forma Nativa a bufferização VSAM deverá ser aplicada para estes arquivos. Buffers nativos são especificados no JCL e irão reduzir a quantidade de EXCPs para estes jobsteps. Economia Projetada: 2 minutos Caso Prático - 25 de 70
JOBs: J217A89D, J217B89D, J217C89D, J217D89D, J217E89D, J217F89D, J217G89D, J217H89D, J217I89D, J217J89D, J217K89D e J217L89D Programa: P207292D Recuperação de CPU O programa executado neste jobstep consome uma grande quantidade de CPU. Todos os JOBs listados acima executam este programa em paralelo. Este programa tem seu maior impacto no uso da CPU do complexo de processadores. Caso Prático - 26 de 70
Como este programa é executado em paralelo uma grande quantidade do recurso CPU é consumida durante esta série de JOBs. A tabela abaixo resume este consumo de CPU. Data 4/11/00 4/12/00 4/13/00 4/14/00 Job CPU Tempo MM:SS CPU Tempo MM:SS CPU Tempo MM:SS CPU Tempo MM:SS J217A89D 4:02 3:04 7:38 2:59 J217B89D 8:42 7:58 8:42 9:22 J217C89D 13:51 12:36 13:45 12:27 J217D89D 11:55 12:05 13:40 11:56 J217E89D 11:50 10:14 11:32 9:29 J217F89D 9:25 9:25 12:11 10:16 J217G89D 9:58 10:38 12:12 9:54 J217H89D 9:34 9:38 11:15 9:50 J217I89D 10:16 10:28 12:10 10:27 J217J89D 9:37 9:31 11:50 9:52 J217K89D 12:17 11:58 12:28 11:08 J217L89D 11:32 12:05 13:40 11:42 Total 2:08 2:00 2:21 2:00 HH:MM HH:MM HH:MM HH:MM Recomendação: O programa P207292D contabilizou um uso de mais de 2 horas e 21 minutos de CPU durante o ciclo de 13 de abril de 2000. Esta quantidade de CPU foi consumida através do uso do complexo de processadores por 1 hora e 40 minutos de tempo relógio parede. Este consumo de CPU afetou toda a carga de trabalho que estava em execução nos processadores naquele momento. Durante o ciclo de 11 de abril de 2000 mais de 2 horas e 8 minutos de CPU foram consumidos em 1 hora e meia de tempo relógio parede. Uma maior atenção deveria ser dada a este programa para recuperar ciclos de CPU. Para recuperar o recurso CPU e mais, reduzir o ciclo batch deste CASE que estamos analisando, o programa fonte de aplicação juntamente com a documentação da ferramenta de medida de uso da CPU poderiam ser enviados para a ATRI para análise. Exemplos destas ferramentas de medida do desempenho de aplicações são o OMEGAMON Inspect e o STROBE. Economia Projetada: Informação adicional requisitada. Caso Prático - 27 de 70
JOBs: J217A89D, J217B89D, J217C89D, J217D89D, J217E89D, J217F89D, J217G89D, J217H89D, J217I89D, J217J89D, J217K89D e J217L89D (continuação) Job Step: P205103D Bufferização BLSR VSAM Este jobstep executa um grande número de EXCPs em vários arquivos VSAM. Alguns destes arquivos VSAM estão listados abaixo. Estes arquivos são compartilhados por este programa em todos os JOBs listados acima. No ciclo batch há mais de 1 milhão de EXCPs executados nestes datasets. Caso Prático - 28 de 70
Recomendação: Nas recomendações gerais há uma referência à facilidade BLSR. Nós recomendamos o uso de uma combinação total de 1.250 buffers de Dados (10 megabytes) e 1.000 de BLSR buffers de Índice (2 megabytes) para estes componentes VSAM. Até que a BSLR seja implementada deve-se utilizar a bufferização VSAM Nativa para estes datasets. Buffers Nativos são especificados no JCL e reduzirão a quantidade de EXCPs para estes jobsteps. Economia Projetada: Deve-se manter este JOB fora do caminho crítico deste ciclo batch. Caso Prático - 29 de 70
JOBs: J217A89D, J217B89D, J217C89D, J217D89D, J217E89D, J217F89D, J217G89D, J217H89D, J217I89D, J217J89D, J217K89D e J217L89D Programa: P205103D Recuperação de CPU Este programa executado neste jobstep consome uma grande quantidade de CPU. Todos os JOBs listados acima executam este programa em paralelo. Este programa tem um grande impacto na CPU do complexo de processadores. Caso Prático - 30 de 70
Como este programa é executado em paralelo uma grande quantidade do recurso CPU é consumida durante a execução desta série de JOBs. A tabela abaixo resume o consumo de CPU pelo programa P205103D. Data 4/11/00 4/12/00 4/13/00 4/14/00 Job CPU Tempo MM:SS CPU Tempo MM:SS CPU Tempo MM:SS CPU Tempo MM:SS J217A89D 3:41 3:16 9:45 3:01 J217B89D 7:16 7:06 7:46 8:14 J217C89D 11:12 11:23 13:06 11:06 J217D89D 11:00 11:08 12:56 11:08 J217E89D 10:21 10:56 12:47 10:26 J217F89D 10:04 10:32 13:25 11:13 J217G89D 10:36 11:27 13:35 11:01 J217H89D 10:21 11:03 13:31 11:09 J217I89D 11:03 11:54 14:06 11:51 J217J89D 10:56 11:15 14:21 11:44 J217K89D 12:15 12:40 14:32 12:45 J217L89D 12:06 12:41 14:52 12:39 Total 2:01 2:06 2:35 2:07 HH:MM HH:MM HH:MM HH:MM Recomendação: O programa P205103D contabilizou por mais de 2 horas e 35 minutos de CPU durante os ciclos dia 13 de abril de 2000. Esta quantidade de CPU foi consumida através do complexo de processadores em mais de 40 minutos de hora relógio parede. O consumo desta quantidade de CPU afetou toda a carga de trabalho que estava executando nos processadores naquele momento. Durante os ciclos do dia 11 de abril de 2005 mais de 2 horas e 1 minuto de tempo de CPU foram consumidas sobre 1hora e meia de hora relógio parede. Atenção deverá ser dada para este programa a fim de recuperar ciclos de CPU. Para recuperar o recurso CPU e reduzir o ciclo batch que estamos analisando neste CASE, o programa fonte da aplicação juntamente com os relatórios de uma ferramenta de medida do desempenho de aplicações deverá ser enviado a ATRI. Exemplos destas ferramentas temos o OMEGAMON Inspect e o STROBE. Economia Projetada: Informação adicional requerida Caso Prático - 31 de 70
JOBs: J215A32D, J215B32D, J215C32D, J215D32D, J215E32D, J215F32D, J215G32D, J215H32D, J215I32D, J215J32D, J215K32D e J215L32D Programa: P207240D Recuperação de CPU O programa executado neste jobstep consome uma grande quantidade de CPU. Todos os JOBs listados acima executam este programa em paralelo. Este programa tem um grande impacto no uso da CPU do complexo de processadores. Caso Prático - 32 de 70
Como este programa é executado em paralelo uma grande quantidade do recurso CPU é consumida durante esta série de JOBs. A tabela abaixo resume este consumo de CPU para o programa P207240D. Job 4/11/00 4/12/00 4/13/00 4/14/00 CPU Tempo MM:SS CPU Tempo MM:SS CPU Tempo MM:SS CPU Tempo MM:SS J215A32D 6:41 5:46 6:33 5:57 J215B32D 17:15 15:43 16:56 19:23 J215C32D 27:34 25:51 27:56 25:44 J215D32D 25:01 24:14 26:58 24:30 J215E32D 23:31 23:40 23:30 22:30 J215F32D 21:16 22:14 25:47 24:46 J215G32D 23:17 24:53 26:02 23:17 J215H32D 21:24 21:55 23:03 22:50 J215I32D 24:00 25:34 26:44 25:10 J215J32D 21:53 22:30 25:52 22:46 J215K32D 25:55 25:03 25:31 25:19 J215L32D 23:09 22:38 26:04 22:54 Total 4:21 4:20 4:41 4:25 HH:MM HH:MM HH:MM HH:MM Recomendação: O programa P207240D contabilizou mais de 4 horas e 41 minutos de tempo de CPU durante o ciclo do dia 13 de abril de 2000. Esta quantidade de tempo foi consumida através do complexo de processadores e levou mais de 1 hora e 30 minutos de tempo relógio parede. Este consumo de CPU afetou toda a carga de trabalho que estava sendo executada naquele momento nos processadores. Durante o ciclo do dia 11 de abril de 2000, mais de 4 horas e 21 minutos de CPU foram consumidas contra 1 hora e meia de relógio parede. Atenção deverá ser dada para este programa a fim de recuperar ciclos de CPU. Para recuperar o recurso CPU e reduzir o ciclo batch que estamos analisando neste CASE, o programa fonte da aplicação juntamente com os relatórios de uma ferramenta de medida do desempenho de aplicações deverá ser enviado a ATRI. Como exemplos destas ferramentas têm o OMEGAMON Inspect e o STROBE. Economia Projetada: Informação adicional requerida Caso Prático - 33 de 70