![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
A reprodução de cargas de trabalho de produção em um ambiente de teste auxilia DBAs a identificar a solidez potencial e problemas de desempenho relacionados a mudanças no ambiente do DB2. Exemplos dessas mudanças são:
- Migração ou atualização do mecanismo do DB2
- Atualização de tabelas e estatísticas de índice
- Instalação de novos plugins de segurança
- Modificação de um servidor de aplicativos
O sistema de teste geralmente não é idêntico ao sistema de produção. Por exemplo, pode ter uma quantidade menor de memória. Para simular com realismo uma carga de trabalho do sistema de produção no sistema de teste, é preciso ajustar a escala do número de usuários e quantidade de memória da instância, bem como os valores dos parâmetros relacionados à memória.
As variáveis que serão usadas para formalizar o ajuste de escala são definidas na próxima seção. O artigo em seguida discute o ajuste de escala do número de usuários e o tamanho da memória das instâncias. Por fim, descreve o ajuste de escala dos demais parâmetros relacionados à memória e script de automação de amostra.
As sete variáveis a seguir são definidas e serão usadas para formalizar o processo de ajuste de escala nas seções a seguir.
- Ip – O tamanho do parâmetro
INSTANCE_MEMORYem um sistema de produção - It – O tamanho do parâmetro
INSTANCE_MEMORYem um sistema de teste
- Up – O número de usuários no sistema de produção
- Ut – O número de usuários no sistema de teste
- N – O número total de parâmetros relacionados à memória
- Mi,p – O tamanho do parâmetro relacionado à memória i-th no sistema de produção
- Mi,t – O tamanho do parâmetro relacionado à memória i-th no sistema de teste
Usuário e memória da instância
Esta seção discute as relações entre o número de usuários e a memória da instância nos sistemas de produção e teste. Para garantir o comportamento consistente, a quantidade de memória alocada para um dado usuário deve ser a mesma nos sistemas de produção e teste.
Se It for fixo, o número máximo de usuários no sistema de teste é dado por Ut = It × Up ÷ Ip .
Considere o exemplo a seguir. Suponha que Ip = 100 Mb, Up = 10 usuários e It = 70 Mb. O número máximo de usuários no sistema de teste seria igual a Ut = 70 × 10 ÷ 100 = 7 usuários.
Se quiser simular um número específico de usuários no sistema de teste, é possível calcular o tamanho da memória da instância do sistema de teste necessária para conseguir isso, usando It = Ut × Ip ÷ Up .
Por exemplo, caso deseje simular cinco usuários no sistema de teste (Ut = 5 usuários), e Ip = 100 Mb e Up =10 usuários, então It = 5 × 100 ÷ 10 = 50 Mb.
Após o número de usuários e tamanho da memória da instância serem configurados, é possível determinar o tamanho dos demais parâmetros de configuração da memória.
Demais parâmetros de configuração da memória
Os demais parâmetros de configuração da memória podem ser determinados usando uma das seguintes abordagens.
- Abordagem restrita – Preserva a mesma proporção em todos os valores dos parâmetros de configuração relacionados à memória nos sistemas de produção e teste. Essa abordagem pode ser usada para simular um sistema de produção com valores fixos de parâmetro relacionados à memória, ou um sistema de produção com carga de trabalho uniforme.
- Abordagem relaxada – Preserva as mesmas proporções para alguns dos valores dos parâmetros de configuração relacionados à memória nos sistemas de produção e teste. Essa abordagem pode ser usada para testar um sistema de produção com parâmetros relacionados à memória gerenciados pelo mecanismo DB2.
Uma abordagem restrita é ideal se todos os parâmetros de configuração da memória no sistema de produção forem fixos. A preservação das proporções de valor dos parâmetros de memória resultará em um sistema de teste realista. No entanto, se alguns dos parâmetros forem configurados para AUTOMATIC e/ou gerenciados pelo Self-Tuning Memory Management (STMM), os valores dos parâmetros podem flutuar à medida que as cargas de trabalho mudarem. Isso implicaria que fixar os valores não resulta em uma visão realista. Há uma exceção a essa regra. Se a carga de trabalho for uniforme, os valores dos parâmetros são estáveis. Isso significa que, mesmo que seja configurado como AUTOMATIC , os valores provavelmente não mudarão. Nesse caso, a abordagem restrita terá bons resultados, mesmo que os parâmetros sejam gerenciados automaticamente.
Se alguns dos parâmetros de memória forem gerenciados automaticamente e forem voláteis, a abordagem relaxada pode proporcionar uma solução mais realista. No entanto, como o tamanho da instância de memória nos sistemas de teste e produção é diferente, o comportamento de gerenciadores de memória automáticos pode diferir nos sistemas e, portanto, podem não levar a resultados de ajuste de escala perfeitos sempre.
Uma técnica de equilíbrio, misturando as abordagens restrita e relaxada, consiste na captura de conjuntos de valores de parâmetros sob diferentes cargas no sistema de produção, e em seguida executar cargas de escala semelhante no sistema de teste com a escala dos valores dos parâmetros ajustadas para cada conjunto de parâmetros.
O restante da seção é estruturado da seguinte forma. Primeiro detalhes adicionais são apresentados sobre a implementação das abordagens restrita e relaxada. Em seguida, a seção script de automação de amostra descreve um script Perl simples que automatiza a implementação dessas abordagens.
Implementação da abordagem restrita
Para preservar as mesmas proporções em todos os parâmetros de memória no sistema de teste, deve-se desativar o STMM e configurar valores AUTOMATIC para valores fixos, aplicando as mesmas proporções para parâmetros de memória no sistema de teste que no sistema de produção. O processo pode ser resumido usando o seguinte algoritmo.
Disable STMM on the test system by executing "UPDATE DB CFG USING self_tuning_mem OFF" For i = 1 .. N Set Mi,t = It × Mi,p ÷ Ip Execute "UPDATE [DB|DBM] CFG USING i-th_config_keyword Mi,t" |
Implementação da abordagem relaxada
A abordagem relaxada é de natureza semelhante à abordagem restrita. No entanto, você permitirá que o sistema de teste gerencie parâmetros de memória que eram gerenciados automaticamente no sistema de produção. É preciso ativar STMM e inicializar parâmetros de memória com valores escalados. Se os valores eram gerenciados automaticamente no sistema de produção, eles podem ser gerenciados automaticamente no sistema de teste. Do contrário, deve-se gerenciá-los manualmente.
O processo pode ser resumido desta forma.
Enable STMM on the test system by executing "UPDATE DB CFG USING self_tuning_mem ON" For i = 1 .. N Set Mi,t = It × Mi,p ÷ Ip If the i-th parameter was set to AUTOMATIC on the production machine Then Execute "UPDATE [DB|DBM] CFG USING i-th_config_keyword Mi,t AUTOMATIC" Else Execute "UPDATE [DB|DBM] CFG USING i-th_config_keyword Mi,t" |
Script de automação de amostra
Um script Perl de amostra chamado memscaling.pm está incluído com este artigo. Esse script automatiza os algoritmos das abordagens restrita e relaxada. O script calcula o fator de escala e emite em um arquivo de texto instruções "update [DB|DBM] cfg" para o sistema de teste.
Quando os dados forem capturados, execute memscaling.pm
em qualquer computador, fornecendo as seguintes opções.
-
--approach_type or -a <c|r> - O tipo de abordagem de ajuste de escala de memória: 'c', restrito, ou 'r', relaxado.
-
--db_cfg or -db <file containing db config> - O nome do arquivo que contém a configuração do banco de dados.
-
--dbm_cfg or -dbm <file containing dbm config> - O nome do arquivo que contém a configuração do gerenciador do banco de dados.
-
--output or -o <output file> - O nome do arquivo de configuração de saída.
-
--param or -p <file containing parameters of interest> - O nome do arquivo que contém os parâmetros de configuração relacionados à memória de interesse que sofrendo ajuste de escala.
-
--test_inst_mem_sz or -s <test instance memory size> - O tamanho da memória disponível para a instância do DB2 no sistema de teste em páginas de 4K.
-
--help ou -h - Fornece documentação adicional.
Para usar o script, é preciso armazenar as configurações de banco de dados e de gerenciador de banco de dados do sistema de produção em arquivos de texto. Pode-se usar o seguinte, por exemplo.
$db2 GET DB CFG > db.cfg $db2 GET DBM CFG > dbm.cfg |
O arquivo que contém parâmetros de configuração relacionados à memória deve ter o seguinte formato: um parâmetro (a saber, uma palavra-chave circundada por parêntese na saída de "get DB | DBM cfg") por linha, sem nenhuma ordem em particular, como mostra a tabela a seguir.
instance_memory db_memory mon_heap_sz |
Este artigo descreveu o ajuste de escala do número de usuários, memória da instância do DB2 e parâmetros de configuração relacionados à memória em um sistema de teste do DB2, baseado na configuração de um sistema de produção do DB2. Essas informações devem ajudar a criar um sistema de teste realista que tenha escala ajustada para produção, melhorando a análise de alterações no sistema de teste.
| Descrição | Nome | Tamanho | Método de download |
|---|---|---|---|
| Sample Perl script automating the algorithms | memscaling.zip | 4KB | HTTP |
Informações sobre métodos de download
Aprender
- Visite o Centro de Informações do DB2 V9.7 para ler um resumo dos parâmetros de configuração do DB2.
- Leia o artigo Visão geral da memória de autoajuste no Centro de Informações do DB2 V9.7.
- Visite o Centro de Informações do DB2 V9.7 para ver uma descrição do comando
get DB cfg. - Visite o Centro de Informações do DB2 V9.7 para ver uma descrição do comando
get DBM cfg. - Participe do fórum de discussão.
- Obtenha os recursos necessários na área de Information Management no developerWorks, para melhorar suas habilidades em uma grande variedade de produtos do IBM Information Management.
- Saiba mais sobre Information Management na zona de Information Management no developerWorks. Encontre documentação técnica, artigos de instruções, treinamento, downloads, informações de produtos, e muito mais.
- Siga o developerWorks no Twitter.
- Acompanhe as demos on demand do developerWorks
que abrangem desde demos de instalação e configuração de produtos para iniciantes até funcionalidade avançada para desenvolvedores experientes.
Obter produtos e tecnologias
- Crie seu próximo projeto de desenvolvimento com a
versão de teste do software IBM, disponível para download diretamente no developerWorks, ou passe algumas horas no SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de modo eficiente.
Discutir
- Participar do fórum de discussão.
- Confira o blog do developerWorks e participe da comunidade do developerWorks.
Enzo Cialini é Membro da Equipe Técnica Senior da divisão de Software Information Management IBM no IBM Toronto Laboratory. É atualmente Arquiteto Chefe de Controle de Qualidade de estratégia de gerenciamento e teste técnico para o Mecanismo LUW do DB2 (Armazém e OLTP) e Criação de Perfil Operacional do Cliente. Enzo passou a fazer parte da IBM em 1991 e trabalha na equipe de desenvolvimento do DB2 desde 1992. Ele tem mais de 20 anos de experiência em desenvolvimento, teste e suporte de software. Enzo participa ativamente junto aos clientes e no campo de implementações de OLTP e Armazém e escreveu The High Availability Guide for DB2 e tem diversas patentes e publicações no DB2 e Integration.
Dr. Miranskyy é desenvolvedor de Controle de Qualidade na divisão de Information Management IBM do IBM Toronto Laboratory. Seus interesses de trabalho e pesquisa estão na área de diminuir o risco na engenharia de software, focando em controle de qualidade de software, compreensão de programa, requisitos de software, arquitetura de software e gerenciamento de risco de projeto. Andriy é PhD em matemática aplicada pela Universidade do Oeste do Ontário. Ele tem 15 anos de experiência em engenharia de software nos segmentos de mercado de gerenciamento de informações e farmacêutico. Andriy tem diversas publicações e patentes no campo de engenharia de software.
