![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
No teste de estabilidade de releases do kernel Linux, há uma necessidade de estabelecer e documentar claramente por que o release está estável ou instável. E embora não documentado e comprovado, existe atualmente o teste de sobrecarga no sistema inteiro que pode testar a estabilidade do kernel Linux na sua totalidade. Este artigo fornece um método para criar um teste de sobrecarga no sistema inteiro e fornecer a legitimidade dos resultados. Diferentes desenvolvedores, usuários e distribuições de Linux, utilizam seus próprios métodos para testar a estabilidade do kernel. No entanto, as informações relativas à base para sua decisão sobre quais testes devem ser executados, o código de kernel coberto e níveis de sobrecarga alcançados não são publicados, o que reduz grandemente o valor dos resultados.
Utilizando máquinas e testes de laboratório disponíveis para Linux a partir do conjunto de testes do Linux Test Project, nós desenvolvemos uma combinação de testes, com base nas estatísticas de utilização de recursos do sistema, para estressar adequadamente o sistema. Nós analisamos esse teste de combinação para determinar quais seções do kernel Linux são exercitadas durante a execução de teste. Posteriormente, nós modificamos o teste de combinação para permitir a mais alta porcentagem de cobertura de código, enquanto mantemos o alto nível de sobrecarga do sistema desejado. O resultado final é um teste de sobrecarga que abrange o suficiente do kernel Linux para ser útil para instruções de estabilidade e que tem o uso do sistema e o dado de cobertura de código de kernel para suportá-lo.
As quatro etapas para esse método de teste de combinação são: seleção de teste, avaliação da utilização de recursos do sistema, análise de cobertura do código de kernel e avaliação final do teste de sobrecarga.
A seleção do teste envolve a seleção de testes que realizam duas coisas:
- Os testes devem permitir a obtenção de níveis de utilização alta de recursos para áreas principais do kernel, como a (s) CPU(s), memória, E/S e interligação de redes.
- Os testes devem cobrir adequadamente o código de kernel para ajudar a suportar a instrução de estabilidade produzida a partir de seus resultados.
Sempre que possível, utilize testes que são automatizados ou facilmente modificados para suportar automação. A automação permite o teste mais rápido e que pode ser repetido, assim como ajuda a reduzir o risco de erro humano. Utilizar aplicativos que permitem a publicação livre de resultados é uma outra consideração ao selecionar testes apropriados. É bom para escolher conjuntos de testes que aderem à metodologia de software livre e/ou ao GPL para ajudar a assegurar um processo de publicação fácil.
Avaliando a Utilização de Recursos do Sistema
A combinação de testes selecionados deve estressar adequadamente os recursos do sistema. Quatro áreas primárias do kernel Linux podem afetar a resposta do sistema e o tempo de execução:
- CPU: Tempo gasto processando dados na(s) CPU(s) da máquina
- Memória: Tempo gasto lendo e gravando dados na memória real e a partir dela
- E/S: Tempo gasto lendo e gravando dados no armazenamento em disco e a partir dele
- Interligação de Redes: Tempo gasto lendo e gravando dados na rede e a partir dela
Os designers de teste devem utilizar as duas seguintes ferramentas bem conhecidas de monitoramento de recursos Linux de software livre para avaliar os níveis de utilização de recursos. (Para obter links para fazer download de ambas as ferramentas, consulte Recursos posteriormente neste artigo.)
- principal: Uma ferramenta de software livre mantida por Albert D. Cahalan, que é incluída na maioria das distribuições Linux e funciona nos kernels 2.4 e 2.6 atuais.
- sar. Outra ferramenta de software livre; essa é mantida por Sebastien Godard. Essa ferramenta também é incluída na maioria das distribuições Linux e funciona nos kernels 2.4 e 2.6 atuais.
Essa fase de avaliação da utilização de recursos do sistema do método geralmente requer múltiplas tentativas na obtenção da combinação correta de testes que alcançarão o nível desejado de utilização. A utilização excessiva é sempre uma preocupação ao decidir sobre a combinação de testes. Por exemplo, escolher uma combinação que seja muito limitada por E/S pode criar resultados precários para a CPU e vice-versa. Essa parte do método consiste primeiramente em uma grande quantidade de tentativa e erro, até que os níveis desejados para todos os recursos sejam alcançados.
A ferramenta principal é útil para determinar rapidamente quais recursos (CPU, memória ou E/S) cada teste afeta e quantos deles ele utiliza de um modo de tempo real. A ferramenta sar é útil para reunir estatísticas de utilização da rede e gravar capturas instantâneas de todos os dados para utilização para um arquivo em um período de tempo.
Logo que uma combinação é escolhida, um teste deve ser executado para uma quantidade estendida de tempo para avaliar precisamente a utilização do recurso. A quantidade de tempo para executar o teste depende do comprimento de cada teste. Supondo que múltiplos testes estejam sendo executados simultaneamente, a quantidade de tempo deve ser longa o suficiente para permitir que o mais longo de todos esses testes seja concluído. A ferramenta sar também deve estar em execução durante essa avaliação. Na conclusão da execução da avaliação, você deve reunir e avaliar os níveis de utilização para todos os quatro recursos.
O seguinte exemplo mostra mostra a saída de sar para CPU, memória e utilização da rede:
Lista 1. Saída de Exemplo a partir de sar
10:48:27 CPU %user %nice %system %iowait %idle 10:48:28 all 0.00 0.00 0.00 0.00 100.00 10:48:29 all 3.00 0.00 1.00 0.00 96.00 10:48:30 all 100.00 0.00 0.00 0.00 0.00 10:48:31 all 100.00 0.00 0.00 0.00 0.00 02:27:31 kbmemfree kbmemused %memused kbswpfree kbswpused %swpused 02:29:31 200948 53228 20.94 530104 0 0.00 02:31:31 199136 55040 21.65 530104 0 0.00 02:33:31 198824 55352 21.78 530104 0 0.00 02:35:31 199200 54976 21.63 530104 0 0.00 02:27:31 IFACE rxpck/s txpck/s rxbyt/s txbyt/s 02:29:31 eth0 738.79 741.66 76025.55 136941.85 02:31:31 eth0 743.30 744.97 76038.82 136907.77 02:33:31 eth0 744.80 745.02 76135.53 136901.38 02:35:31 eth0 742.35 744.34 75947.45 136864.77 |
Analisando a Cobertura do Código de Kernel
Alcançar a cobertura adequada de kernel é uma outra responsabilidade de um teste de sobrecarga do sistema. Apesar de a combinação escolhida de testes utilizar extensivamente os quatro recursos principais, ela pode apenas estar executando um pequeno subconjunto do kernel. Assim, é necessário analisar a cobertura para assegurar que a combinação se presta a ser um teste de sobrecarga do sistema e não um gerador de carga do sistema. Atualmente, duas ferramentas de software livre podem ajudar na análise de cobertura de código do kernel Linux:
- gcov: Uma ferramenta de software livre mantida pelo Linux Test Project. Essa ferramenta analisa a cobertura do kernel e relata quais linhas, funções e ramificações são cobertas e como muitas vezes elas foram atingidas.
- lcov: Uma ferramenta de software livre desenvolvida pela IBM e mantida do pelo Linux Test Project. Essa ferramenta consiste em um conjunto de scripts Perl que é construído na saída de gcov baseada em texto para implementar a saída baseada em HTML. A saída inclui porcentagens de páginas de cobertura, gráfico e visão geral que permitem a navegação rápida de dados de cobertura. É possível localizar ambas as na página inicial do Linux Test Project (LTP) (consulte Recursos para obter um link).
Após o módulo gcov estar carregado, todos os testes executados na combinação de teste de sobrecarga do sistema devem ser executados. Embora o teste de sobrecarga do sistema original possa e deva ter execuções simultâneas, essa execução deve ser iterativa. Cada teste deve ser executado uma vez até a conclusão, um após o outro, sem repetição de nenhum teste. A execução única e iterativa é uma tentativa para reduzir a quantidade de execuções de código de kernel imprevisível e sem destino que resulta da tentativa do kernel de balancear a carga das múltiplas execuções simultâneas do teste de sobrecarga do sistema. É necessário executar a análise gcov após a conclusão da execução de teste final. Como a etapa final na formulação de dados para análise, execute a ferramenta lcov e descarregue o módulo gcov.
A ferramenta lcov gera uma árvore HTML inteira que contém cada linha de código no kernel e dados sobre quantas vezes, se houver, cada linha foi executada. A ferramenta quantifica os dados de cobertura e gera números percentuais de cobertura para cada seção e arquivo do kernel. O seguinte exemplo mostra uma saída de cobertura de código de amostra:
Figura 1. Exemplo de Saída de gcov
Os mantenedores de lcov definiram "cobertura adequada" (verde) e, dessa forma, o exemplo de lcov é simplesmente um parecer. No entanto, o dados brutos incluídos permitem que qualquer revisor faça seu próprio julgamento. O criador do teste pode agora fazer alterações na combinação de testes após rever a análise de cobertura, para alterar e/ou aumentar a quantidade de códigos cobertos.
Avaliando o Teste de Sobrecarga Final
A verificação do teste de sobrecarga do sistema é a razão para essa etapa final no método. Execute o teste de sobrecarga em um kernel tido como estável; geralmente o kernel incluído em uma distribuição preencherá esse requisito, mas não sempre. Execute o teste de sobrecarga por um período estendido (mínimo de 24 horas recomendado), com a ferramenta sar em execução também, por duas razões:
- A execução estendida ajudará a encontrar qualquer problema dentro da combinação que, de outra maneira, teria passado despercebida em um curto "teste de olfato".
- O dado produzido a partir de sar forma sua comparação de linha de base em futuras execuções de teste.
Após a conclusão da execução estendida, você agora está apto a decidir, com base em todos os dados reunidos, se essa combinação de teste é um bom candidato ou não para teste de sobrecarga do sistema.
Figura 2. Resumo do Processo de Design
O Linux Test Project utilizou esse método de design ao projetar o script de teste de sobrecarga do kernel ltpstress.sh. Esse aplicativo combina múltiplos testes de áreas diferentes do conjunto de testes do LTP, junto com geradores de memória e de carregamento de tráfego de rede. Antes de executar, o teste ajusta sua utilização da memória total de acordo com a quantidade de memória real e virtual existente no sistema. Esse script de teste está disponível através do conjunto de testes do LTP (consulte Recursos). O script foi criado sob condições de laboratório controladas para assegurar a exatidão dos resultados.
O departamento do Centro de Tecnologia IBM Linux utiliza esse teste de sobrecarga, junto com outras ferramentas e testes, como uma maneira relativamente rápida e fácil para validar a estabilidade dos releases de kernel Linux. Testes são conduzidos sob condições do laboratório, assim como sob cenários do cliente simulados, para ajudar a assegurar a cobertura adequada.
-
Faça download do script de shell de teste de sobrecarga e de um grupo de outros testes
úteis na página inicial do Linux Test Project.
-
A missão do Centro de Tecnologia
IBM Linux é trabalhar diretamente com a comunidade de desenvolvimento
Linux com uma visão compartilhada para tornar o Linux bem-sucedido.
-
A Linux Kernel
Scalable Test Platform (STP) do OSDL fornece uma estrutura em que os desenvolvedores
podem testar correções do kernel contra o desempenho e o conjunto de escalabilidade on-line.
-
O teste de sobrecarga do LTP faz uso dos utilitários
principais(parte do pacote procps ) esar(parte do systat). -
Além disso, o teste de sobrecarga do LTP faz bom uso do programa de cobertura
de teste do GNU, o gcov e de seus resultados de gcov baseados em Perl, o lcov em html.
-
Comparação
do Kernel: Aperfeiçoamentos no Desenvolvimento de Kernel a partir de 2.4 até 2.6
(developerWorks, fevereiro de 2004) examinam as ferramentas, testes e
técnicas que ajudaram a tornar 2.6 um kernel melhor que qualquer que tenha vindo
antes dele.
-
Comparação
do Kernel: Entrega da Web no 2.4 e 2.6 (developerWorks, fevereiro de 2004)
apresenta resultados dos esforços de teste de entrega da Web do Centro de Tecnologia
IBM Linux.
-
No Melhorando
o Desempenho e a Escalabilidade do Kernel Linux (developerWorks, janeiro de
2003), a equipe de Desempenho do Kernel Linux do Centro de Tecnologia Linux discute como quantificar o desempenho do Linux para o propósito de comparar resultados
de teste periodicamente.
-
Colocando
a Confiabilidade do Linux em Teste (developerWorks, dezembro de 2003) documenta
os resultados de teste e a análise do kernel Linux e outro componente do S.O. de
núcleo pelo Centro de Tecnologia IBM Linux.
-
Por dentro do
Depurador do Kernel Linux (developerWorks, junho de 2003) mostra como
rastrear a execução do kernel e examina sua memória e estruturas de dados.
- Encontre mais recursos para desenvolvedores Linux na developerWorks.
- Navegue em Manuais nesses e em outros tópicos técnicos.
- Desenvolva e teste seus aplicativos Linux utilizando as mais recentes ferramentas IBM
e middleware com uma Assinatura do developerWorks: obtenha o software IBM a partir do
WebSphere®, DB2®, Lotus®, Rational® e Tivoli®, bem como uma licença para utilizar
o software por 12 meses, tudo por menos dinheiro do que se imagina.
- Faça download de versões experimentais sem encargos de produtos de
Assinatura do developerWorks selecionados que são executados no Linux, incluindo WebSphere Studio Site
Developer, WebSphere SDK para serviços da Web, WebSphere Application Server,
DB2 Universal Database Personal Developers Edition, Tivoli Access Manager
e Lotus Domino Server, a partir da seção Acelere-inicie seu aplicativo Linux do developerWorks.Para um início ainda mais rápido,
aproveite uma coleta produto por produto de artigos com instruções e suporte à
tecnologia.
Robbie Williamson é um Engenheiro Administrativo de Software no Centro de Tecnologia IBM Linux. Ele se formou na Universidade do Texas com um bacharelado em Ciência da Computação em 2000. Durante sua carreira, ele trabalhou como um técnico em suporte, engenheiro de verificação e desenvolvedor para várias implementações de UNIX. Robbie é atualmente um dos mantenedores para o Linux Test Project e pode ser encontrado em robbiew@us.ibm.com. Nota: Este artigo representa a visão do autor e não necessariamente representa a visão da IBM. As descobertas discutidas neste artigo são baseadas em uma solução que foi criada e testada em condições de laboratório. Essas descobertas podem não ser realizadas em todos os ambientes do cliente e a implementação em tais ambientes pode requerer etapas, configurações e análise de desempenho adicionais. As informações aqui contidas são fornecidas NO ESTADO EM QUE SE ENCONTRAM sem garantias, expressas ou implícitas. Essas informações não constituem uma especificação ou parte do formulário da garantia para qualquer produto IBM. A implementação e a certificação da solução depende da equipe de implementação.
