gerenciamento de desempenho de servidores unix

UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
GERENCIAMENTO DE DESEMPENHO DE SERVIDORES
UNIX
FLAIMISSON ELIÉZER SCARPINI
BLUMENAU
2006
2006/2-03
FLAIMISSON ELIÉZER SCARPINI
GERENCIAMENTO DE DESEMPENHO DE SERVIDORES
UNIX
Trabalho de Conclusão de Curso submetido à
Universidade Regional de Blumenau para a
obtenção dos créditos na disciplina Trabalho
de Conclusão de Curso II do curso de Sistemas
de Informação - Bacharelado.
Prof. Wilson Pedro Carli - Orientador
BLUMENAU
2006
2006/2-03
GERENCIAMENTO DE DESEMPENHO DE SERVIDORES
UNIX
Por
FLAIMISSON ELIÉZER SCARPINI
Trabalho aprovado para obtenção dos créditos
na disciplina de Trabalho de Conclusão de
Curso II, pela banca examinadora formada
por:
Presidente:
WILSON PEDRO CARLI – Professor Orientador - FURB
Membro:
ANTONIO CARLOS TAVARES – Professor da Banca – FURB
Membro:
FRANCISCO ADELL PÉRICAS – Professor da Banca – FURB
Blumenau, 11 de dezembro de 2.006
Dedico este trabalho a todos os analistas de
suporte que trabalham diariamente com
servidores Unix (Hp-Ux) onde possuem a
responsabilidade
de
zelar
pelo
acompanhamento diário do desempenho dos
sistemas.
AGRADECIMENTOS
À Empresa Bunge Alimentos, mais precisamente ao gerente da
Tecnologia da
Informação - Silvio Heusi, a gerente de Tecnologia/Infra-Estrutura e Operações – Mônica
Gueths e também ao Analista de Processos – Antonio Carlos Kauling pela oportunidade e
confiança depositada bem como por terem cedido os servidores da empresa para a criação do
software de análise de desempenho.
Ao meu orientador, professor Wilson Pedro Carli, pelas valiosas e oportunas
informações
para que este trabalho possa servir de base para
aprimoramento de soluções.
futuras consultas ou
Tu te julgas superior ? Que chato! Deves ter
algo de mais em teu corpo: Quatro pernas,
duas cabeças, sei lá.
Álvaro Luiz de Aguiar
RESUMO
Este trabalho descreve o desenvolvimento de um software que tem como função monitorar e
acompanhar os recursos computacionais do sistema operacional Unix permitindo um
gerenciamento pró-ativo, eficaz e com baixo custo. Devido a mudanças constantes nas
aplicações, faz-se necessário criar mecanismos de gerenciamento de desempenho para
identificar contenções no processamento dos servidores as quais geram lentidão ou perdas
financeiras para as empresas. Através das informações coletadas e analisadas, é possível
evitar ou minimizar os problemas de desempenho obtendo com isso um melhor
aproveitamento dos equipamentos e melhorando os níveis de serviços.
Palavras-chave: Sistema de Informação. Desempenho. Sistema operacional Unix.
ABSTRACT
This article describes the development of a software that has as function to monitor and to
follow the computational resources of the Unix operational system being allowed a
management pro-asset, efficient and with low cost. Due to constant changes in the
applications, one becomes necessary to create mechanisms of performance management to
identify containments in the processing of the servers which generate financial slowness or
losses for the companies. Through the collected and analyzed information, it is possible to
prevent or to minimize the performance problems getting with this one better exploitation of
the equipment and improving the levels of services.
Key-words: Information Systems. Performance. Unix operational system.
LISTA DE ILUSTRAÇÕES
Figura 1 – Fornecedores Mundiais de Software de Gerenciamento - Gartner (2005) ........... 15
Figura 2 - Tripé......................................................................................................................... 17
Figura 3 - Ambiente Complexo ............................................................................................... 18
Figura 4 – Software de Gerenciamento - Gartner (2005)....................................................... 21
Quadro 1- Requisitos Funcionais ............................................................................................. 23
Quadro 2 - Requisitos Não-Funcionais .................................................................................... 24
Figura 5 – Topologia Física...................................................................................................... 25
Figura 6 – Ciclos do Desenvolvimento .................................................................................... 26
Quadro 3 – Resumo das Métricas............................................................................................. 29
Quadro 4 – Alarme cpu em modo user..................................................................................... 31
Quadro 5 – Alarme cpu em modo sys ...................................................................................... 32
Quadro 6 – Alarme consumo e/s .............................................................................................. 33
Quadro 7 – Alarme fila de processamento ............................................................................... 34
Quadro 8 – Alarme consumo de memória................................................................................ 35
Quadro 12 – Detalhamento das fases ....................................................................................... 36
Figura 7 – Acessando o sistema ............................................................................................... 37
Figura 9 – Exibição dos parâmetros processados..................................................................... 39
Figura 10 – Comparando resultados......................................................................................... 40
Figura 11– Métricas diversas.................................................................................................... 41
Quadro 9 – Código fonte shell.................................................................................................. 42
Quadro 10 – Código fonte do coletor de cpu ........................................................................... 43
Quadro 11 – Código fonte de exibição dos gráficos ................................................................ 44
Figura 12 – Parecer da empresa................................................................................................ 46
LISTA DE SIGLAS
ABNT
– Associação Brasileira de Normas Técnicas
CPU
– Central Processing Unit . Unidade Central de Processamento
E/S
– Dispositivos de Entrada e Saída das informações.
HP
– Hewllet Packard Company U.S.A. Fabricante de Servidores Unix
HP-UX
– Sistema Operacional Unix da Empresa Hewllet Packard Company U.S.A.
ITIL
– Information Techology Infrastructure Libray
LAN
– Local Area Network
PERL
– Linguagem de Programação nativa do HP-UX
SAN
– System Area Network
UNIX
– Marca Registrada de Open Group U.S.A.
SUMÁRIO
1 INTRODUÇÃO.................................................................................................................. 12
1.1 OBJETIVOS...................................................................................................................... 13
1.2 ESTRUTURA DO TRABALHO ...................................................................................... 14
1.3 MOTIVADORES .............................................................................................................. 14
1.4 OBSERVAÇÕES .............................................................................................................. 15
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 16
2.1 MÉTRICAS....................................................................................................................... 18
2.2 SISTEMA ATUAL ........................................................................................................... 19
2.3 NECESSIDADES.............................................................................................................. 20
2.4 TRABALHOS CORRELATOS........................................................................................ 20
3 DESENVOLVIMENTO DO TRABALHO ..................................................................... 22
3.1 LEVANTAMENTO E ANÁLISE .................................................................................... 22
3.2 PREMISSAS E LINGUAGENS UTILIZADAS .............................................................. 22
3.3 REQUISITOS DO SISTEMA........................................................................................... 23
3.4 TOPOLOGIA FÍSICA....................................................................................................... 25
3.5 CICLOS DO DESENVOLVIMENTO.............................................................................. 26
3.6 DEFINIÇÃO DAS MÉTRICAS ....................................................................................... 26
3.6.1 Métrica de CPU em modo USER.................................................................................... 27
3.6.2 Métrica de CPU em modo SYS ....................................................................................... 27
3.6.3 Métrica de E/S................................................................................................................. 27
3.6.4 Métrica de fila de processamento.................................................................................... 28
3.6.5 Métrica de consumo de memória .................................................................................... 28
3.6.6 Quadro resumo das métricas ........................................................................................... 29
3.7 AGENTES COLETORES................................................................................................. 30
3.8 TRATAMENTO DE ALERTAS ..................................................................................... 30
3.9 EXIBIÇÃO DOS GRÁFICOS .......................................................................................... 30
4 EXEMPLOS DE RECEBIMENTO DOS ALARMES................................................... 31
4.1 CPU EM MODO USER.................................................................................................... 31
4.2 CPU EM MODO SYS....................................................................................................... 32
4.3 E/S ..................................................................................................................................... 33
4.4 FILA DE PROCESSAMENTO ........................................................................................ 34
4.5 MEMÓRIA........................................................................................................................ 35
5 IMPLEMENTAÇÃO......................................................................................................... 36
5.1 ETAPAS ............................................................................................................................ 36
5.1.1 Acessando o sistema ....................................................................................................... 37
5.1.2 Solicitando os parâmetros para análise ........................................................................... 37
5.1.3 Exibição entre períodos das métricas............................................................................. 39
5.2 VALIDAÇÃO DOS RESULTADOS OBTIDOS ............................................................ 40
5.2.1 Exibindo várias métricas ................................................................................................. 41
5.2.2 Código do aplicativo de métricas.................................................................................... 42
5.2.3 Código do aplicativo coletor de desempenho ................................................................. 43
5.2.4 Código do aplicativo de exibição dos gráficos ............................................................... 44
6 CONCLUSÕES.................................................................................................................. 45
6.1 EXTENSÕES .................................................................................................................... 46
7 BIBLIOGRAFIA ............................................................................................................... 47
12
1 INTRODUÇÃO
A Bunge Alimentos está presente no Brasil desde 1.905. É a mais importante empresa
na industrialização de soja e trigo. É líder na comercialização de grãos como soja, trigo,
milho, sorgo, girassol e semente de algodão. É líder também na exportação brasileira no agronegócio estando presente em 16 estados brasileiros, com unidades industriais de
armazenamento, moinhos, centros de distribuição, escritórios e terminais portuários. Sua sede
está localizada em Gaspar, S.C. Para chegar onde está, a empresa investiu e está investindo
em tecnologias da informação e comunicação, principalmente em computadores servidores e
redes de computadores que interligam as suas várias unidades industriais e escritórios por
todo o Brasil (BUNGE ALIMENTOS, 2005) .
Num plano de continuidade dos negócios, o uso racional e equilibrado dos recursos de
informática é primordial para a empresa. A adoção de uma tecnologia que possibilita ter a
visualização dos recursos operacionais utilizados nos computadores pode contribuir para que
ocorra uma estabilidade associada com escalabilidade nas aplicações corporativas. Isso se
reflete em ganhos financeiros para a empresa, pois as interrupções não programadas nos
sistemas são substancialmente reduzidas através do gerenciamento efetivo.
Segundo Klauck (1999), o gerenciamento de redes de computadores pode ser
conceituado como a coordenação de controle de atividades e monitoração do uso. Atualmente
os recursos computacionais estão cada vez mais rápidos e eficazes, porém, existem situações
que, mesmo nos mais modernos equipamentos, surgem gargalos no processamento das
informações gerando atrasos e prejuízos para as empresas. Os custos elevados para novos
investimentos inibem na maioria dos casos a troca do servidor, porém é possível identificar
previamente onde está localizado o baixo desempenho no servidor, utilizando um sistema de
gerenciamento de desempenho.
13
Um sistema parcialmente parado ou operando com muita deficiência, pode
comprometer não somente a imagem da empresa como também sofrer sanções judiciais. Não
é por acaso que nos últimos 10 anos tem-se dado expressivo valor para a metodologia de
gerenciamento de processos da tecnologia de informação denominada
Information
Techology Infrastructure Library (ITIL). Na metodologia, existem 04 níveis de
gerenciamento que prezam por esta qualidade. São eles:
a) gerenciamento de capacidade;
b) gerenciamento de disponibilidade;
c) gerenciamento de continuidade;
d) gerenciamento de níveis de serviço.
Desta forma, é imprescindível que haja nos servidores das empresas um gerenciamento
de desempenho compatível com a sua necessidade de negócio.
1.1
OBJETIVOS
O objetivo deste trabalho é desenvolver um software para o gerenciamento de
desempenho de servidores Unix, especificamente o HP-UX versão 11.23, capaz de exibir
graficamente os recursos computacionais utilizados pelo servidor com elevado grau de
confiabilidade, pró-atividade e custos reduzidos comparados a outros softwares de mercado.
Os objetivos específicos do trabalho foram:
a) identificar o consumo dos recursos de CPU, memória, disco e fila de
processamento no servidor;
b) identificar a ociosidade e picos de demanda em determinados períodos, exibindoos graficamente através de aplicativos web;
c) gerar alerta pró-ativamente do consumo dos recursos monitorados;
14
d) realizar planejamento de capacidade (capacity plan) do servidor.
1.2
ESTRUTURA DO TRABALHO
A seguir será descrito resumidamente os capítulos do referido trabalho.
O primeiro capítulo apresenta a introdução, os objetivos, os motivadores e as
observações do trabalho e seu público alvo.
O segundo capítulo apresenta a fundamentação teórica com conceitos e entendimentos
sobre o tema análise de desempenho, métricas de acompanhamento e o sistema atual.
Também informa o sistema atual com suas atribuições e necessidades. Consta também os
trabalhos correlatos.
O terceiro e o quarto capítulos, relatam o desenvolvimento, os requisitos e definições
da forma que o gerenciamento funciona
e
principalmente
detalhamento das métricas
monitoradas.
No capítulo cinco encontra-se um resumo dos principais códigos fontes.
No capítulo seis tem-se o resumo da implementação, forma de acesso e resultados
obtidos.
Por fim, no capítulo 7 são apresentadas as principais conclusões do trabalho bem como
sugestões para futuras melhorias.
1.3
MOTIVADORES
No mercado mundial existem várias soluções dos grandes fornecedores de
hardwares/softwares que possuem aplicativos de gerenciamento de desempenho
para
servidores Unix. Os líderes de mercado segundo a publicação do órgão internacional de
divulgação de tecnologia, o Gartner Group (GARTNER, 2005), conforme o Figura 1, são o
15
Tivoli (IBM TIVOLI, 2005), Patrol (BMC PATROL, 2005), Unicenter (CA UNICENTER,
2005) e o Perfview (OPENVIEW,2005).
Figura 1 – Fornecedores Mundiais de Software de Gerenciamento - Gartner (2005)
Todos os softwares possuem renomados conceitos
na análise de desempenho de
servidores. Porém, tanto o custo do software quanto da customização e implementação, são
demasiadamente altos para a maioria das empresas. Sendo assim, a criação de um software
de análise de desempenho com eficiência semelhante aos produtos de mercado, foi um dos
motivadores do trabalho proposto.
1.4
OBSERVAÇÕES
Não faz parte deste trabalho instruir ou certificar qualquer pessoa a fazer análise de
desempenho de servidores Unix sem capacitação técnica do assunto.
O uso do software desenvolvido neste trabalho é destinado exclusivamente para
administradores de servidores Unix com pelo menos 02 anos de experiência e 01 ano
especificamente em ambiente HP-UX.
16
2 FUNDAMENTAÇÃO TEÓRICA
Segundo Specialski (1999), a adoção de um software de gerenciamento não resolve
todos os problemas da pessoa responsável pela administração. Ao ser analisado o desempenho
de um único recurso isolado do servidor e o mesmo recurso reportar que está todo alocado,
pode-se chegar a uma conclusão errônea dos fatos. Isto se deve a característica do
processamento no servidor Unix.
Às vezes um recurso a 100% não significa que está esgotado e sim que está utilizando
toda a sua disponibilidade naquele momento ou para aquele grupo de processos.
Um exemplo prático disto seria imaginarmos uma estrada em que somente um único
veículo estivesse trafegando do ponto A para o ponto B. Nesse trajeto, o veículo gastaria 01
hora e a estrada seria considerada 100% livre.
Caso outros 50 veículos realizassem o mesmo percurso em 01 hora, teríamos a
situação de 100 % de ocupação da estrada, porém não teríamos nenhum tipo de contenção ou
gargalo. Somente teríamos um tipo de contenção ou gargalo se estes 50 veículos levassem
mais de 01 hora para fazer o percurso.
Outro fator de extrema importância que deve ser entendido refere-se ao
desbalanceamento no uso do servidor e/ou nas configurações do sistema operacional. Tais
fatores poderão influenciar diretamente no desempenho do servidor. No sistema operacional,
existem valores que devem ser configurados para extrair o máximo de desempenho dos
recursos. Esse valores estão contidos no núcleo do sistema operacional denominado kernel.
É no kernel onde habilita-se dar mais recursos ou menos para os processos, sejam eles
em capacidade de alocação de memória, de arquivos abertos, máximo de transações
permitidas ou ainda uma infinidade de parâmetros que visam dar mais desempenho ao
servidor.
17
A ampliação do servidor também requer demasiada cautela. Não adianta mudar um
ponto com contenção, sejam eles (CPU, Memória e E/S), pois corre-se o risco de afetar outro.
Seria o mesmo que alterar um dos lados de um tripé conforme a Figura 2 .
Figura 2 - Tripé
Caso alterar quaisquer dos pontos acima sem critérios operacionais ao invés de
resolver um determinado problema, pode-se mover o problema para outro local causando um
desbalanceamento. Na prática isto poderá ocorrer quando expandir o poder de processamento
da CPU. Como o servidor terá maior capacidade de processamento, provavelmente irá
solicitar ou repassar mais processamento para os outros recursos.
Somando-se a isto, deve-se avaliar a infra-estrutura onde o servidor está instalado.
Isto é necessário, pois nos ambientes atuais existem uma série de outros elementos que são
passíveis de causarem alguma influência no desempenho do servidor. Na Figura 3, podemos
visualizar um cenário com maior complexidade onde existem servidores, storages, switches,
rede lan, rede san.
18
Storage
BKP
PROD
Espelhamento e Alta Disponibilidade
BKP
PROD
Swtiches SAN
Caminhos Alternativos
Rede de Servidores
Figura 3 - Ambiente Complexo
2.1
MÉTRICAS
A definição das métricas de gerenciamento de desempenho são necessárias para que o
servidor possa operar dentro de uma faixa de normalidade no consumo dos recursos de (CPU,
Memória e E/S). Caso alguma métrica seja ultrapassada, pode-se prejudicar o rendimento do
servidor ou a utilização dos aplicativos.
Em servidores que operam em chão de fábrica ou linha de produção onde o consumo
dos recursos são mais equilibrados, as métricas poderão ser mais próximas do seu limite de
funcionamento. Já em servidores com aplicações comerciais, deve-se usar critérios mais
conservadores pois as oscilações são muito rápidas e caso uma métrica esteja próxima do seu
limite, pode-se não ter tempo hábil para uma tomada de ação corretiva. Como exemplo,
pode-se comparar um processo de envasamento onde não podem existir atrasos sob pena de
19
comprometer o processo e um processo de emissão de relatórios onde um atraso de segundos
é tolerável.
É importante ter conhecimento do ambiente pois isso irá nortear as definições das
métricas. Métricas muito altas ou mais baixas, não devem ser efetivadas devido aos riscos de
um possível colapso no sistema. É função do administrador, envolver todos os responsáveis
pelos softwares do servidor para um alinhamento dos parâmetros de níveis de monitoração.
Outro ponto importante, é que jamais se deve aplicar a mesma regra de gerenciamento
para servidores de uso diferenciados, pois cada tipo de processamento poderá ter
particularidades específicas.
2.2
SISTEMA ATUAL
A Bunge Alimentos possui em todos os seus servidores Unix a plataforma de
gerenciamento chamada Perfview (OPENVIEW, 2005) configurada de forma pró-ativa e
com indicadores de análise de desempenho. Este software, fornece todas as informações do
uso de (CPU, Memória e E/S) e também gera alarmes automáticos quando alguma métrica é
ultrapassada reportando-a ao administrador do servidor para que seja tomada alguma ação.
O software possui estatísticas gráficas de uso ao longo do tempo possibilitando um
acompanhamento diário dos recursos utilizados. Isso possibilita realizar o planejamento de
capacidade (capacity plan) do servidor de forma eficiente.
20
2.3
NECESSIDADES
Em várias situações, ocorreram necessidades de utilizar um novo servidor Unix por
períodos curtos. Apesar da brevidade do uso, era necessário ter a monitoração implementada
também neste equipamento.
O prazo para obtenção de novas licenças para os servidores eram demasiadamente
longas e complexas. Quando as mesmas chegavam, o servidor já estava praticamente na fase
final dos testes. Isto gerava vários problemas, pois algumas validações não eram realizadas
corretamente no quesito CPU, Memória e E/S.
Diante disso, decidiu-se elaborar um novo software de gerenciamento de desempenho
de menor porte, mas de tal forma que os resultados fossem mais próximos possíveis do
software atual e com extrema rapidez na implementação.
2.4
TRABALHOS CORRELATOS
No mercado mundial, existem várias soluções dos grandes fornecedores de
hardwares/softwares que possuem softwares de gerenciamento de desempenho
para
servidores Unix. Os mais utilizados, segundo uma publicação do órgão internacional de
divulgação de tecnologia, o Gartner Group (GARTNER, 2005), são o Tivoli (IBM TIVOLI,
2005), Patrol (BMC PATROL, 2005), Unicenter (CA UNICENTER, 2005) e o Openview.
O OpenView, é a
plataforma de gerenciamento utilizada atualmente na Bunge
Alimentos. Conforme Hewlett-Packard Development Company (1995), esta plataforma
possui característica centralizada de gerenciamento, onde uma infinidade de aplicativos de
gerência e monitoração são agregados no mesmo ambiente criando uma visão única. No caso
21
do gerenciamento de análise de desempenho, o OpenView utiliza-se do Perfiview. O Perfview
permite realizar análises de CPU, memória, E/S e redes de forma gráfica e com recursos
muito sofisticados (HEWLETT-PACKARD DEVELOPEMENT COMPANY, 2002).
No
mesmo nível de detalhamento do OpenView, existem os produtos Unicenter,Tivoli e Patrol,
que desempenham funcionalidades praticamente iguais ao do Openview e que também são
softwares multiplataforma. A única consideração com relação a todos estes produtos é o seu
alto custo de aquisição.
Indiferente da escolha do produto, um dos objetivos além do gerenciamento em si do
produto é a sua eficácia e retorno do investimento que o software agrega. Na pesquisa
realizada pelo Gartner Group (GARTNER, 2005), indicou um alto grau de satisfação dos
produtos. A Figura 4, mostra que 60 % das respostas entre as empresas usuárias dos
softwares, relataram que obtiveram retorno de investimento no adoção das ferramentas de
gerenciamento em suas plataformas.
Figura 4 – Software de Gerenciamento - Gartner (2005)
22
3 DESENVOLVIMENTO DO TRABALHO
Esta fase tratou dos levantamentos e definições do novo software de gerenciamento.
3.1
LEVANTAMENTO E ANÁLISE
Foi necessário definir quais elementos e limites seriam monitorados pelo software de
gerenciamento de desempenho baseado no limite máximo de cada item. Entre eles tem-se:
a) central processing unit (CPU) : gerenciar de 0% a 100 % utilização da CPU;
b) memória do servidor: gerenciar de 0% a 100 % a utilização da memória;
c) fila de processos na CPU: gerenciar de 1 a 99 processos;
d) utilização do(s) acesso(s) ao(s) discos (input/output – I/O) : gerenciar de 0% a
100% a utilização do acesso aos discos;
e) uso da pró-atividade, alertando sempre que algum recurso esteja sendo usado
acima da métrica especificada pelo administrador do servidor.
3.2
PREMISSAS E LINGUAGENS UTILIZADAS
A infra-estrutura necessária utilizada para o desenvolvimento e operação da software
de gerenciamento de desempenho foi composta de:
a) servidor HP com sistema operacional HP-UX versão 11.00, 11.11 ou 11.23;
b) compilador C;
c) interpretador Shell;
d) interpretador Perl;
e) software Apache nativo do sistema operacional.
23
3.3
REQUISITOS DO SISTEMA
O Quadro 1 apresenta os requisitos funcionais que foram implementados.
Requisitos Funcionais
Implementados
RF01: O administrador do servidor define as métricas de gerenciamento
SIM
RF02: O administrador faz a ativação dos aplicativos no servidor.
SIM
RF03: Os aplicativos fazem coletas de os dados e gravam em arquivos.
SIM
RF04: A monitoração identifica o valor coletado, faz a comparação e envia
SIM
alarmes para o administrador do sistema quando necessário.
RF05: O administrador acessa o sistema através de um browser.
SIM
RF06: O administrador informa o período que deseja analisar os recursos
SIM
utilizados pelo servidor.
RF07: O sistema processa as informações solicitadas pelo administrador.
SIM
RF08: O sistema exibe os dados graficamente.
SIM
RF09: O administrador analisa os gráficos e toma de ação caso alguma
SIM
métrica esteja acima do especificado.
Quadro 1- Requisitos Funcionais
24
O Quadro 2 abaixo, apresenta os requisitos não funcionais que foram implementados.
Requisitos Não Funcionais
Contemplados
RNF01: O sistema executa em ambiente HP-UX versão 11.23.
SIM
RNF02: Servidor HP-UX versão 11.23 deverá possuir um webserver
SIM
(Apache) o qual disponibilizará as informações de monitoramento.
RNF03: O administrador do servidor
deverá acessar o sistema por
intermédio de um browser padrão de mercado como
SIM
Internet Explorer ou
Firefox.
RNF04: Caso o acesso ao software seja realizado via Internet, existe a
SIM
necessidade de configurar regras de firewall.
RNF05: O sistema deverá utilizar protocolo TCP/IP para conexão do usuário
até o servidor.
Quadro 2 - Requisitos Não-Funcionais
SIM
25
3.4
TOPOLOGIA FÍSICA
A infra-estrutura do funcionamento do novo software de gerenciamento foi elaborada
para ser de baixa complexidade e concentrar-se somente num único equipamento. Isto
simplificou o acesso às informações de tal forma para que qualquer computador na rede, fosse
capaz de acessar o software. Na Figura 5, pode-se verificar como o software de
gerenciamento de desempenho atual no ambiente com o(s) administrador(es) de Unix através
da infra-estrutura de rede e o servidor.
Figura 5 – Topologia Física
26
3.5
CICLOS DO DESENVOLVIMENTO
A Figura 6,
mostra como foram desenvolvidos os
ciclos do
software de
gerenciamento de desempenho pois a seqüência permitiu separar de forma clara todos os
pontos de atuação tanto no desenvolvimento quanto na implementação do software.
Figura 6 – Ciclos do Desenvolvimento
3.6
DEFINIÇÃO DAS MÉTRICAS
É muito importante conhecer o ambiente e o servidor que se deseja monitorar pois
para cada tipo, deve-se adotar medidas eficientes e que sejam benéficas. Não adianta ter
métricas muito pequenas, pois o sistema poderá gerar centenas de alertas. Por outro, não deve
deixar as métricas muito próximas do seu limite máximo, pois isso deixa muito pouco tempo
para uma possível intervenção do administrador.
Nesta etapa, definiram-se os parâmetros máximos que o sistema alerta quando algum
dos recursos computacionais ultrapassam o valor definido e também que ação executar.
27
3.6.1
Métrica de CPU em modo USER
A métrica CPU em modo USER, significa a quantidade de processador alocada para os
processos das aplicações, excluindo-se o sistema operacional. O consumo de CPU oscila entre
0% a 100% . Esta métrica ficou estabelecida em 90% de utilização. Caso este valor for
ultrapassado, o sistema gera um alerta ao administrador do servidor através de e-mail,
enviando também todos os processos que estavam consumindo CPU naquele momento.
3.6.2
Métrica de CPU em modo SYS
Um outro parâmetro monitorado foi o consumo de CPU pelo sistema operacional, ou
seja, em modo SYS. Este parâmetro informa o quanto a CPU está trabalhando para atender as
chamadas do sistema operacional. Foi estipulado que este parâmetro jamais deve ser superior
ao da CPU. Caso ultrapassar, o mesmo é alertado para o administrador.
3.6.3
Métrica de E/S
Mesmo com Storages de alta capacidade, é necessário monitorar este recurso. Este
consumo de E/S oscila entre 0% a 100% . Foi definido que esta métrica ficará estabelecida
em 40% de utilização. Caso este valor seja ultrapassado, o sistema alerta o administrador do
servidor através de email, enviando também a identificação de todos os nomes dos processos
que estavam consumindo recursos de E/S naquele momento e também qual era o periférico
de E/S mais utilizado.
28
3.6.4
Métrica de fila de processamento
Mesmo em sistemas multi-processados, toda requisição de processamento pelo sistema
operacional, passa por uma fila de processamento. O consumo da fila de processamento oscila
entre 00 a 99. Foi definido que esta métrica ficará estabelecida em 02. Caso este valor seja
ultrapassado, o sistema também gera alerta ao administrador através de e-mail, enviando a
identificação de todos os processos que estavam consumindo recursos de CPU e o valor da
fila de processamento naquele momento.
3.6.5
Métrica de consumo de memória
De acordo com recomendações do fabricante do servidor e com análises internas dos
baseadas nos processos da empresa, foi definido que o limite ficasse em 70% de ocupação.
29
3.6.6
Quadro resumo das métricas
No Quadro 3, consolida-se as ações dos alarmes definidas na fase de levantamento. É
importante mencionar que se pode incluir qualquer outra ação que se faça necessária a
qualquer momento.
MÉTRICA
CPU em Modo USER
CPU em Modo SYS
VALOR
> 90 %
> CPU em
AÇÃO
•
•
Modo USER
E/S
> 40 %
•
•
Capturar
DESTINO
todos
Enviar por email ao
os processos em
administrador
execução.
servidor.
Capturar
todos
Enviar por email ao
os processos em
administrador
execução.
servidor.
Capturar
todos
administrador
execução.
servidor.
o
periférico
que
do
Enviar por email ao
os processos em
Identificar
do
do
esteja gerando o
problema.
FILA de PROCESSAMENTO
>2
•
•
Capturar
todos
Enviar por email ao
os processos em
administrador
execução.
servidor.
do
Fazer estatística
do consumo das
filas.
MEMÓRIA
> 70 %
•
•
Capturar
todos
Enviar por email ao
os processos em
administrador
execução.
servidor.
Capturar
o
consumo
de
memória
de
todos
os
processos.
Quadro 3 – Resumo das Métricas
do
30
3.7
AGENTES COLETORES
A forma de coletar os dados dos recursos consumidos ocorre através de dois
aplicativos que executam paralelos e continuamente no servidor. O primeiro aplicativo tem a
função de coletar dados da (CPU, Memória e Fila de Processos) e o segundo, tem a função
de coletar dados do E/S. Todo o armazenamento foi feito em arquivos no formato American
Standard Code for Information Interchange (ASCII).
3.8
TRATAMENTO DE ALERTAS
Da mesma forma que os aplicativos coletores, foi criado um terceiro aplicativo em
linguagem Shell, onde estão configuradas as métricas e ações que devem ser realizadas caso
alguma seja ultrapassada. Se isto acontecer, o aplicativo coletor envia uma mensagem através
de email ao administrador do sistema com as informações necessárias para análise
relacionadas no item 3.3.6.
3.9
EXIBIÇÃO DOS GRÁFICOS
Depois dos dados coletados e armazenados nos arquivos, são disponibilizados para o
administrador acessá-los graficamente através de um aplicativo Web para fazer as devidas
análises.
31
4 EXEMPLOS DE RECEBIMENTO DOS ALARMES
Neste capítulo, são apresentados como os alarmes são recebidos pelo administrador do
servidor.
4.1
CPU EM MODO USER
Os alertas recebidos sobre a métrica definida para CPU em modo USER, contém todas
as informações do que estava sendo processado no instante do alerta, conforme demonstrados
no exemplo no Quadro 4 abaixo na coluna USER.
------ 12/11/2006 19:02:24 Gargalo CPU USER ( 90) ----
System: c0590 Sun Nov 12 19:02:29 2006
Load averages: 0.68, 0.93, 0.88
254 processes: 220 sleeping, 34 running
Cpu states:
CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS
0 0.06 0.4% 0.0% 0.0% 99.6% 0.0% 0.0% 0.0% 0.0%
1 1.30 1.0% 0.0% 1.0% 98.0% 0.0% 0.0% 0.0% 0.0%
--- ---- ----- ----- ----- ----- ----- ----- ----- ----avg 0.68 0.6% 0.0% 0.4% 99.0% 0.0% 0.0% 0.0% 0.0%
Memory: 812676K (123028K) real, 526668K (109432K) virtual, 2132040K free Page# 1/16
CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
1 ? 1779 oracleem 152 20 176M 143M run 198:24 2.12 2.12 native_thr
0 ? 33 root 152 20 1856K 0K run 20:26 1.25 1.24 vxfsd
1 ? 2353 root 154 20 18308K 9876K sleep 418:36 1.20 1.20 netmon
1 ? 2724 precise 152 20 214M 61480K run 45:04 0.60 0.60 P
1 ? 2357 root 152 20 30580K 7908K run
6:21 0.55 0.55 ovoareqsdr
1 ? 1488 root -16 20 23052K 5288K run 72:24 0.54 0.54 midaemon
1 ? 2671 precise 152 20 208M 37504K run 12:32 0.38 0.38
0 ? 2686 precise 152 20 215M 50048K run 17:43 0.36 0.36 bin
1 ? 2693 precise 152 20 210M 42764K run 13:57 0.34 0.34 1.3.1
0 ? 2351 root 154 20 9076K 4896K sleep 31:44 0.29 0.29 DLTtrapdest
0 ? 2377 root 152 20 30656K 7296K run
1:18 0.25 0.25 opcdispm:
1 ? 1835 oracleem 168 20 22364K 2712K sleep 22:26 0.25 0.25 dbsnmp
0 ? 2373 root 152 20 23008K 2712K run 85:42 0.23 0.22 opcactm
1 ? 3 root 128 20 32K 0K sleep 24:03 0.21 0.21 statdaemon
1 ? 1572 root 152 20 101M 85900K run 11:15 0.20 0.20 rds
0 ? 2426 root 152 20 17968K 4720K run
1:09 0.19 0.19 opcctla
UID PID PPID C STIME TTY
TIME COMMAND
root 0 0 0 Nov 5 ?
0:18 swapper
root 1 0 0 Nov 5 ?
1:55 init
Quadro 4 – Alarme cpu em modo user
32
4.2
CPU EM MODO SYS
Da mesma forma, ocorre com a métrica definida para CPU em modo SYS, conforme
demonstrados no Quadro 5 na coluna SYS.
------ 12/11/2006 19:02:24 Gargalo CPU SYS ( 32) -----
System: c0590 Sun Nov 12 19:02:29 2006
Load averages: 0.68, 0.93, 0.88
254 processes: 220 sleeping, 34 running
Cpu states:
CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS
0 0.06 0.4% 0.0% 0.0% 99.6% 0.0% 0.0% 0.0% 0.0%
1 1.30 1.0% 0.0% 1.0% 98.0% 0.0% 0.0% 0.0% 0.0%
--- ---- ----- ----- ----- ----- ----- ----- ----- ----avg 0.68 0.6% 0.0% 0.4% 99.0% 0.0% 0.0% 0.0% 0.0%
Memory: 812676K (123028K) real, 526668K (109432K) virtual, 2132040K free Page# 1/16
CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
1 ? 1779 oracleem 152 20 176M 143M run 198:24 2.12 2.12 native_thr
0 ? 33 root 152 20 1856K 0K run 20:26 1.25 1.24 vxfsd
1 ? 2353 root 154 20 18308K 9876K sleep 418:36 1.20 1.20 netmon
1 ? 2724 precise 152 20 214M 61480K run 45:04 0.60 0.60 P
1 ? 2357 root 152 20 30580K 7908K run
6:21 0.55 0.55 ovoareqsdr
1 ? 1488 root -16 20 23052K 5288K run 72:24 0.54 0.54 midaemon
1 ? 2671 precise 152 20 208M 37504K run 12:32 0.38 0.38
0 ? 2686 precise 152 20 215M 50048K run 17:43 0.36 0.36 bin
1 ? 2693 precise 152 20 210M 42764K run 13:57 0.34 0.34 1.3.1
0 ? 2351 root 154 20 9076K 4896K sleep 31:44 0.29 0.29 DLTtrapdest
0 ? 2377 root 152 20 30656K 7296K run
1:18 0.25 0.25 opcdispm:
1 ? 1835 oracleem 168 20 22364K 2712K sleep 22:26 0.25 0.25 dbsnmp
0 ? 2373 root 152 20 23008K 2712K run 85:42 0.23 0.22 opcactm
1 ? 3 root 128 20 32K 0K sleep 24:03 0.21 0.21 statdaemon
1 ? 1572 root 152 20 101M 85900K run 11:15 0.20 0.20 rds
0 ? 2426 root 152 20 17968K 4720K run
1:09 0.19 0.19 opcctla
UID PID PPID C STIME TTY
TIME COMMAND
root 0 0 0 Nov 5 ?
0:18 swapper
root 1 0 0 Nov 5 ?
1:55 init
root 2 0 0 Nov 5 ?
0:14 vhand
root 3 0 0 Nov 5 ?
24:03 statdaemon
root 4 0 0 Nov 5 ?
6:41 unhashdaemon
root 8 0 0 Nov 5 ?
0:00 supsched
root 9 0 0 Nov 5 ?
0:00 strmem
root 10 0 0 Nov 5 ?
0:00 strweld
Quadro 5 – Alarme cpu em modo sys
33
4.3
E/S
No alerta de consumo de E/S , ou seja, no acesso aos discos, além do recebimento dos
processos que estavam em execução, é recebida a informação de qual é o disco do servidor
que apresenta problemas. Esta informação é fundamental para o administrador saber onde
está localizado o problema conforme Quadro 6 na coluna device.
------ 12/11/2006 19:13:08 Gargalo E/S IO ( 70) -----
HP-UX c0590 B.11.00 U 9000/800
11/12/06
19:13:08 device %busy avque r+w/s blks/s avwait avserv
19:13:09 c1t0d0 2.97 0.50
4
63 4.50 8.58
19:13:10 c2t0d0 14.00 0.50
20 234 4.92 7.26
c1t0d0 2.00 0.50
4
64 5.47 4.17
19:13:11 c2t0d0 3.96 0.60
10
91 3.33 23.74
c1t0d0 0.99 0.50
2
32 4.43 5.11
19:13:12 c2t0d0 3.00 0.50
5
32 3.05 6.94
c1t0d0 2.00 0.50
3
48 4.54 7.55
19:13:13 c2t0d0 11.00 0.50
14 126 3.87 8.31
c1t0d0 1.00 0.50
2
32 1.00 8.18
c1t2d0 1.00 0.50
1
16 7.19 5.77
Average
Average
Average
Average
c1t0d0
c2t0d0
c1t2d0
c2t2d0
1.30
3.19
0.20
0.10
0.50
0.52
0.50
0.50
2
5
0
0
37 3.97 6.85
48 4.10 10.89
3 7.52 5.78
2 0.49 9.92
System: c0590 Sun Nov 12 19:02:29 2006
Load averages: 0.68, 0.93, 0.88
254 processes: 220 sleeping, 34 running
Cpu states:
CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS
0 0.06 0.4% 0.0% 0.0% 99.6% 0.0% 0.0% 0.0% 0.0%
1 1.30 1.0% 0.0% 1.0% 98.0% 0.0% 0.0% 0.0% 0.0%
--- ---- ----- ----- ----- ----- ----- ----- ----- ----avg 0.68 0.6% 0.0% 0.4% 99.0% 0.0% 0.0% 0.0% 0.0%
Memory: 812676K (123028K) real, 526668K (109432K) virtual, 2132040K free Page# 1/16
CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
1 ? 1779 oracleem 152 20 176M 143M run 198:24 2.12 2.12 native_thr
0 ? 33 root 152 20 1856K 0K run 20:26 1.25 1.24 vxfsd
1 ? 2353 root 154 20 18308K 9876K sleep 418:36 1.20 1.20 netmon
1 ? 1488 root -16 20 23052K 5288K run 72:24 0.54 0.54 midaemon
1 ? 2671 precise 152 20 208M 37504K run 12:32 0.38 0.38
0 ? 2686 precise 152 20 215M 50048K run 17:43 0.36 0.36 bin
1 ? 2693 precise 152 20 210M 42764K run 13:57 0.34 0.34 1.3.1
0 ? 2351 root 154 20 9076K 4896K sleep 31:44 0.29 0.29 DLTtrapdest
0 ? 2377 root 152 20 30656K 7296K run
1:18 0.25 0.25 opcdispm:
1 ? 1835 oracleem 168 20 22364K 2712K sleep 22:26 0.25 0.25 dbsnmp
Quadro 6 – Alarme consumo e/s
34
4.4
FILA DE PROCESSAMENTO
De todos os parâmetros, talvez esse seja o mais importante. Ele mostra ao
administrador quantos processos estão sendo contingenciados pela CPU. Abaixo, no Quadro
7, este parâmetro está identificado na coluna runq-sz.
------ 12/11/2006 19:27:41 Gargalo Fila de Processamento ( 3 ) -----
HP-UX c0590 B.11.00 U 9000/800
11/12/06
19:27:41 runq-sz %runocc swpq-sz %swpocc
19:27:42 0.0
0 0.0
0
19:27:43 0.0
0 0.0
0
19:27:44 0.0
0 0.0
0
19:27:45 0.0
0 0.0
0
19:27:46 0.0
0 0.0
0
19:27:47 1.0
50 0.0
0
19:27:48 1.0
51 0.0
0
19:27:49 1.0
50 0.0
0
19:27:50 2.0
51 0.0
0
19:27:51 3.0
49 0.0
0
Average
1.6
25 0.0
0
System: c0590 Sun Nov 12 19:27:56 2006
Load averages: 0.99, 0.94, 0.96
260 processes: 224 sleeping, 36 running
Cpu states:
CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS
0 0.51 99.4% 0.0% 0.6% 0.0% 0.0% 0.0% 0.0% 0.0%
1 1.47 2.8% 0.0% 2.4% 94.8% 0.0% 0.0% 0.0% 0.0%
--- ---- ----- ----- ----- ----- ----- ----- ----- ----avg 0.99 51.1% 0.0% 1.6% 47.3% 0.0% 0.0% 0.0% 0.0%
Memory: 889984K (173660K) real, 612632K (176836K) virtual, 2048956K free Page# 1/17
CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
1 ? 16660 precise 237 20 91648K 61028K run
2:48 40.73 40.66 pss_tuner.90
1 ? 1779 oracleem 152 20 176M 143M run 198:51 2.08 2.08 native_thr
1 ? 16666 oracleem 154 20 161M 3116K sleep 0:27 1.66 1.66 oraclec0590oem
1 ? 2353 root 154 20 18308K 9876K sleep 418:41 1.37 1.37 netmon
1 ? 33 root 152 20 1856K 0K run 20:28 1.27 1.27 vxfsd
1 ? 1488 root -16 20 23052K 5288K run 72:34 0.64 0.64 midaemon
1 ? 2357 root 152 20 30580K 7908K run
6:22 0.58 0.58 ovoareqsdr
1 ? 2724 precise 152 20 216M 62060K run 45:15 0.47 0.47 P
1 ? 2671 precise 152 20 208M 37504K run 12:35 0.40 0.40
Quadro 7 – Alarme fila de processamento
35
4.5
MEMÓRIA
Quando a quantidade de memória consumida for superior a 70 % de toda a memória
física do servidor, o administrador recebe um email com todos os processos e seus respectivos
consumo de memória de cada processo. Na coluna SZ do Quadro 8, esta quantidade deverá ser
multiplicada por quarto para representar o valor em kbytes. Isto é necessário devido a
particularidades do sistema operacional HP-UX.
------ 12/11/2006 20:53:33 Gargalo De Memoria Usada 2936012 -----
1003 S
FS
`UID PID PPID C PRI NI ADDR SZ
WCHAN TTY
TIME COMD
1003 S
0 0 0 0 128 20
b94c10 0
996060 ?
0:18 swapper
141 S
0 1 0 0 168 20
42fd0700 115 400003ffffff0000 ?
1:56 init
1003 S
0 2 0 0 128 20
43128500 0
12ce9e8 ?
0:15 vhand
1003 S
0 3 0 0 128 20
43128800 0
996060 ?
24:18 statdaemon
1003 S
0 4 0 0 128 20
43128b00 0
b37568 ?
6:45 unhashdaemon
1003 S
0 8 0 0 100 20
42cd1900 0
e89ea0 ?
0:00 supsched
1003 S
0 9 0 0 100 20
42cd1c00 0
b36d38 ?
0:00 strmem
1003 S
0 10 0 0 100 20
42cd1f00 0
d342f8 ?
0:00 strweld
1003 S
0 11 0 0 100 20
43128200 0
b36f58 ?
0:00 strfreebd
1003 S
0 12 0 0 -32 20
43128e00 0
b338e0 ?
7:35 ttisr
1003 S
0 18 0 0 147 20
42fd0a00 0
b36428 ?
0:00 lvmkd
1003 S
0 19 0 0 147 20
42fd0d00 0
b36428 ?
0:00 lvmkd
1003 S
0 20 0 0 147 20
42fd6000 0
b36428 ?
0:00 lvmkd
1003 S
0 21 0 0 147 20
42fd6300 0
b36428 ?
0:00 lvmkd
1003 S
0 22 0 0 147 20
42fd6600 0
b36428 ?
0:00 lvmkd
1003 S
0 23 0 0 147 20
42fd6900 0
b36428 ?
0:00 lvmkd
1003 S
0 24 0 0 148 20
42fd6c00 0
8003f0 ?
0:00 lvmschedd
1003 S
0 25 0 0 100 20
42fd6f00 0
-?
0:00 smpsched
1003 S
0 26 0 0 100 20
42fe5200 0
-?
0:00 smpsched
1003 S
0 27 0 0 100 20
42fe5500 0
-?
0:00 sblksched
1003 S
0 28 0 0 100 20
42fe5800 0
-?
0:00 sblksched
1S
0 2468 1 0 156 20
4a844f00 23
40fc1000 console 0:00 getty
1S
0 647 1 1 154 20
43c59f00 11
b34e88 ?
20:43 syncer
1S
0 44 1 0 148 20
42fb8d00 73
431bc690 ?
0:00 emcpdaemon
1003 R
0 33 0 0 152 20
43188300 0
-?
20:43 vxfsd
1003 S
0 45 0 0 148 20
43180600 0
43180390 ?
0:00 emcpProcd
1003 S
0 46 0 0 148 20
42fd0500 0
43180790 ?
0:23 emcpd
1003 S
0 47 0 0 148 20
43188b00 0
43180f90 ?
0:00 emcpdfd
1003 S
0 48 0 0 148 20
43188e00 0
43180e90 ?
0:44 emcpwdd
1003 S
0 49 0 0 148 20
435ef100 0
43180890 ?
0:00 emcpstratd
0 50 0 0 148 20
435ef400 0
431bc990 ?
0:00 MpAsyncIoDaemo
Quadro 8 – Alarme consumo de memória
36
5 IMPLEMENTAÇÃO
As fases de implementação do software de análise de desempenho, foram dividas em
três etapas distintas descritas a seguir.
5.1
ETAPAS
O Quadro 12 abaixo, mostra o detalhamento das 3 fases. São elas:
ETAPA
OBJETIVO
RESULTADO
1.
Definição do local de execução dos programas no
/usr/local/Multitask/mtperf/var/sar
servidor.
2.
3.
Definição da forma de inicializar os aplicativos de
Foram inseridos na rotina automática de
coleta e de monitoração denominados :
processamento do HP-UX denominada cron
•
Mtperf_CPU
•
Métricas
Habilitação do aplicativo web Apache.
com a periodicidade de 1 em 1 minuto.
Inserido no arquivo /opt/hpws/apache/conf
Quadro 12 – Detalhamento das fases
37
5.1.1
Acessando o sistema
O acesso ao sistema é realizado através de um browser como o Internet Explorer ou
Firefox, conforme a Figura 7 acessando o endereço de web http://10.170.10.12. O sistema
exibe dois campos sendo o código de empresa e a senha do servidor que está sob
responsabilidade do administrador Unix.
Figura 7 – Acessando o sistema
5.1.2
Solicitando os parâmetros para análise
O Administrador do sistema informa os parâmetros solicitados de acordo com os
campos exibidos na tela tais como, data inicial, data final, horários, métricas e cores para
visualização. Ao final, deve clicar no campo Processa para a execução do processamento
conforme Figura 8.
38
Tela(s)
TEL002 – Solicitação dos Parâmetros de análise
Figura 8 – Solicitando os parâmetros
39
5.1.3
Exibição entre períodos das métricas
O sistema acessa os arquivos coletados e exibe as informações graficamente,
permitindo ao administrador identificar o comportamento e consumo de cada parâmetro
conforme Figura 9. Esta visão, permite:
a) identificar o recurso que está com consumo inapropriado;
b) identificar horários com demanda alta ou baixa de processamento;
c) realizar ajustes no sistema operacional, dependendo dos recursos contingenciados;
d) realizar estudo de planejamento de capacidade.
Figura 9 – Exibição dos parâmetros processados
40
5.2
VALIDAÇÃO DOS RESULTADOS OBTIDOS
Para validar o grau de confiabilidade das informações do novo software, foram
comparados os resultados com o software Perfview (OPENVIEW,2005) o qual a Bunge
utiliza em vários servidores. Na Figura 10, mostra a comparação entre os dois aplicativos.
Nota-se que o novo software mostrou além da memória ocupada, a quantidade de memória
total disponível. Isso agrega na análise do administrador realiza, quando da existência de
muitos servidores no ambiente.
Figura 10 – Comparando resultados
41
5.2.1
Exibindo várias métricas
Na Figura 11, estão exibidas todas as métricas solicitadas num determinado período de
dias. Isto permite ao administrador, fazer um plano de capacidade dos recursos alocados.
Caso identifique algum recurso que esteja próximo do limite, poderá tomar alguma
ação pró-ativa para evitar um provável gargalo no processamento.
Figura 11– Métricas diversas
42
5.2.2
Código do aplicativo de métricas
Possui a função de tratar e configurar as métricas definidas para o envio de alarmes.
Foi desenvolvido em linguagem Shell. A opção por esta linguagem foi devido a agilidade na
configuração. Uma parte do código fonte está contido no Quadro 9.
USR=10
SYS=20
IO=30
RQ=2
MEM=70
cd /usr/local/Multitask/mtperf/var/sar
arquivo=`ls -1 mtperf_*.log`
tail -1 $arquivo > /usr/tmp/log1
usr=`cat /usr/tmp/log1 | awk -F " " ' { print $14 } ' `
sys=`cat /usr/tmp/log1 | awk -F " " ' { print $15 } ' `
io=`cat /usr/tmp/log1 | awk -F " " ' { print $16 } ' `
rq=`cat /usr/tmp/log1 | awk -F " " ' { print $2 } ' `
> /usr/tmp/c0590-ok.txt
if [ $usr > $USR ]
then
echo "\n\n ------ `date '+%d/%m/%Y %T'` Gargalo CPU USER ( $usr ) ----- \n\n" >> /usr/tmp/c0590-ok.txt
top -f /usr/tmp/c0590-ok.txt
ps -ef >> /usr/tmp/c0590-ok.txt
fi
MemoriaOcupada=0
Calc1=`echo phys_mem_pages/D | adb -k /stand/vmunix /dev/kmem | tail -1 | cut -d: -f2| tr -d " "`
MemoriaFisica=`expr $Calc1 \* 4 `
Calc2=`vmstat | tail -1 | awk -F " " ' { print $5 } ' `
MemoriaLivre=` expr $Calc2 \* 4 `
MemoriaOcupada=`expr $MemoriaFisica - $MemoriaLivre`
CA1=`expr $MemoriaFisica \* $MEM`
CA2=` expr $CA1 / 100`
if [ $CA2 > $MemoriaLivre ]
then
echo "\n\n ------ `date '+%d/%m/%Y %T'` Gargalo De Memoria Usada $CA2 ----- \n\n" >> /usr/tmp/c0590ok.txt
ps -el > /usr/tmp/c0590-ok.txtfi
Quadro 9 – Código fonte shell
43
5.2.3
Código do aplicativo coletor de desempenho
Coleta os dados de CPU, memória, E/S e fila de processamento. Foi desenvolvido em
linguagem C por uma questão de melhor desempenho e interação com o kernel. No Quadro
10, tem-se uma parte do código fonte.
#include <stdio.h>
#include <sys/param.h>
#include <sys/pstat.h>
#include <unistd.h>
int Verbose = 0;
main(ac, av)
int ac;
char *av[];
{
struct pst_static pst;
struct pst_dynamic psd;
struct pst_vminfo psv;
struct pst_swapinfo pss;
int n, nVezes, idx, PaginaEmKb, wUsr, wSys, wWio;
int wHelp = 0, NumeroDeVezes = 0x7ffffffe, Intervalo = 60;
long TotalDeMemoria, TotalMemoriaOcupada, TotalDeSwap, TotalSwapLivre,
TotalSwapOcupado;
long w_cpu_time_tot;
long w_cpu_time[4];
/* 0 - %usr, 1 - %sys, 2 - %idle, 3 - %wio */
while ((n = getopt(ac, av, "hvn:i:t:")) != -1) {
switch (n) {
case 'v':
Verbose = 1;
break;
case 'n':
NumeroDeVezes = atoi(optarg);
break;
case 'i':
Intervalo = atoi(optarg);
break;
PaginaEmKb = pst.page_size / 1024;
TotalDeSwap = TotalSwapLivre = idx = 0;
while (pstat_getswap(&pss, sizeof(pss), (size_t) 1, idx) > 0) {
TotalSwapLivre += (pss.pss_nfpgs * PaginaEmKb);
if (pss.pss_flags & SW_BLOCK) {
TotalDeSwap += pss.pss_nblks;
} else if (pss.pss_flags & SW_FS) {
TotalDeSwap += (pss.pss_allocated * pss.pss_swapchunk);
}
idx = pss.pss_idx + 1;
Quadro 10 – Código fonte do coletor de cpu
44
5.2.4
Código do aplicativo de exibição dos gráficos
Abaixo, no Quadro 11 está o código fonte do aplicativo Web que foi desenvolvido em
da linguagem Perl por ser mais aderente ao HP-UX e consumir poucos recursos do servidor.
Este aplicativo, integra-se com o software Apache o qual é nativo do HP-UX.
#!/usr/bin/perl
#
# $Id: mtperf.cgi,v 1 $
#
use lib '/usr/local/Multitask/mtperf/cgi-bin';
#use warnings;
use MTRotinas;
use CGI qw/:standard/;
my (@Empresas, @CPU, $Empresa, $CPU, $Posicao);
my $StatusMsg='window.status="MC";return true;';
my %mainColor = (
"alink" => "BLUE",
"bgcolor" => "#CCCCFF",
"bgcolor" => "WHITE",
"link" => "BLUE",
"text" => "BLUE",
"vlink" => "BLUE",
);
print &header();
$Empresa=&param('Empresa');
$Empresa=~s/ +//g if ($Empresa);
$CPU=&param('CPU');
$CPU=~s/ +//g if ($CPU);
&PreparaOpcoes($DirLog);
print &start_html({-title=>'Define parametros', -onLoad=>$StatusMsg,
%mainColor}),
&comment('$Id: mtperf.cgi,v 1.6 2005/01/12 12:40:37 $'),
&meta({'-HTTP-EQUIV'=>'Pragma', -CONTENT=>'no-cache'}),
&start_multipart_form({-method=>'post', -name=>'win', -target=>"_blank",
-action=>"ProcessaGrafico_FURB.cgi"}), "\n",
&div({-align=>'Center'},
&h1("Analisador de Performance - $CPU"),
&br(), &hr({-width=>'50%'}), &br(),
&table(
&Tr(
&td({-align=>'Right'}, &b("Data inicial : ")),
&td({-align=>'Left'}, &input({-type=>'text', -name=>'DataInicio',
-value=>$DataInicio, -size=>10})),
),
&Tr(
Quadro 11 – Código fonte de exibição dos gráficos
45
6 CONCLUSÕES
O objetivo principal do trabalho foi alcançado com sucesso pois todos os propósitos
foram atingidos tais como :
Os objetivos específicos do trabalho foram:
a) identificação do consumo dos recursos de CPU, Memória, E/S e fila de
processamento;
b) identificação dos picos de demanda em determinados períodos;
c) exibição dos históricos de utilização dos recursos do servidor através de gráficos;
d) envio de alertas quando alguma métrica foi ultrapassada;
e) baixo custo de implementação e agilidade na configuração;
f) manter os dados coletados depositados num único equipamento reduzindo a
complexidade de manutenções instalações;
g) facilidade de acesso ao software de gerenciamento de desempenho através.
46
É importante mencionar que opinião semelhante, é compartilhada também pela
empresa conforme Figura 12, onde ratifica os objetivos atingidos.
Figura 12 – Parecer da empresa
O trabalho também foi válido por agregar conhecimento e mostrar que em alguns
casos, o novo software forneceu informações mais detalhadas que o atual.
Por outro lado, é importante frisar que na resolução de problemas complexos, se faz
necessário o uso de outros softwares mais específicos de acordo com o tipo de cada aplicação
seja ela comercial ou industrial.
6.1
EXTENSÕES
Existem vários melhoramentos que poderão ser incorporados neste trabalho como, por
exemplo, à guarda das informações coletadas num banco de dados padrão de mercado. Isso
facilitaria futuras consultas e interligações com outros aplicativos. Porém, esta melhoria deve
ser avaliada com extrema cautela, para que não onere os custos e ou a complexidade do
software para a implantação nos servidores. Outra possível evolução seria permitir mais de
um nível de alarme, classificando-os em categorias de criticidade.
Por fim, deve-se evitar que o software de gerenciamento de desempenho seja um
consumidor de recurso no sistema operacional.
47
7 BIBLIOGRAFIA
BEZZERA, Eduardo. Princípios de análise e projetos de sistemas com UML. Rio de
Janeiro: Campus, 2002.
BMC
Patrol.
Software
de
gerenciamento.
Disponível
<http://www.bmc.com/products/products_services_detail/0,,0_0_0_2001,00.html>.
em 07 nov. 2005
em:
Acesso
BUNGE
ALIMENTOS
S/A.
Disponível
em:
<http://www.bungealimentos.com.br/institucional/aempresa/bungealimentos.asp>. Acesso em
07 nov. 2005
CA
UNICENTER.
Software
de
gerenciamento.
Disponível
<http://www.ca.com/products/unicent/whitepap.htm>. Acesso em: 07 nov. 2005
em:
GARTNER. Órgão internacional de divulgação de análises e pesquisas sobre a indústria
global de tecnologia da informação. Disponível em: <http://www.gartner.com>.Acesso em:
07 nov. 2005
HEWLETT-PACKARD DEVELOPMENT COMPANY. Resource and performance
management ( HP ) Helwett Packard. Copyright Hewlett-Packard Company 1993-1995.
HEWLETT-PACKARD DEVELOPMENT COMPANY. Using HP perfview to view HPUX workload manager performance metrics. [S.l.], 2002. Disponível em:
<http://www.hp.com/products1/unix/operating/docs/perfview_howto.html>. Acesso em: 07
nov. 2005
Software
de
gerenciamento.
Disponível
IBM
TIVOLI.
<http://www.ibm.com/br/products/software.tivoli/>. Acesso em: 07 nov. 2005
em:
KLAUCK, Hugo A. Gerência de redes ATM utilizando CORBA e SMNP. 1999. 51 F.
Trabalho Individual ( Mestrado em Ciências da Computação ) – Depto de Informática e de
Estatística, Universidade Federal de Santa Catarina, Florianópolis.
OPENVIEW HEWLETT-PACKARD DEVELOPMENT COMPANY. Plataforma de
gerenciamento. Disponível em: < http://www.openview.hp.com >. Acesso em: 07 nov. 2005
SPECIALSKI, Elizabeth. Gerência de redes de computadores e telecomunicações. 1999.
51 f. Notas de Aula . Departamento de Informática e de Estatística, Universidade Federal de
Santa Catarina, Florianópolis.