Responder a este comentário
Como identificar problemas de performance / lentidão
Quando temos um banco de dados (seja ele Informix, Oracle, SqlServer, MySql, Postgre, DB2, Sybase ou outro) que está apresentando lentidão não proporcional a carga do sistema (usuários, dados) e capacidade de processamento do hardware (CPU, memória e I/O de disco) o trabalho de identificar a causa desta lentidão é algo que considero um trabalho de detetive. Resolver esta lentidão já é um outro problema pois você poderá depender de terceiros.
Neste artigo não tenho como passar todas as técnicas e detalhes de como realizar este trabalho, mas irei passar algo como um checklist do que você deve verificar.
- Quando posso considerar que tenho um problema de performance?
- Dependências
- Linha de pensamento
- Itens para serem monitorado e verificados
- Comandos
- Recomendação
- Alguns links
Quando posso considerar que tenho um problema de performance?
Primeiramente, é preciso identificar qual das opções abaixo é a sua situação:
- Se você já tem um ambiente em funcionamento que performa de modo satisfatório para o seu negócio e de um certo momento em diante ele passa sofrer de lentidão, sendo que não houve modificações em sua infra-estrutura e software.
- Seu ambiente já se encontra em funcionamento e houve uma mudança de infra-estrutura
- Seu ambiente é novo e não performa conforme sua espectativa.
Dependências
Para certas situações será necessário acesso como administrador/root na maquina, portanto dependendo de quem seja a pessoa que tenha este acesso e o nível de segurança aplicada ao ambiente você terá de entrar em contato com o responsável.
Para identificar alguns itens no nivel de Sistema Operacional talvez precise de utilitários que não tenha instalado no sistema, então terá que conversar com o administrador para resolver a situação.
Também será necessário o levantamento de informações com as pessoas/gestores responsáveis pela infra-estrutura e softwares utilizados.
Linha de pensamento
Para situações onde acredita que não está utilizado seus recursos de hardware do modo mais completo possível, algo que você sempre precisa ter em mente é o seguinte:
- Alterações no seu ambiente, como configuração de RAID de discos, alteração de cabeamentos de rede ethernet e SAN, aumento na quantidade de usuários ao sistema, alterações na lógica dos programas utilizados e novos softwares sendo executados no ambiente.
- Para problemas de performance, poderá haver algum gargalo, ou seja, um ponto que esteja segurando o processamento. Este ponto pode ser I/O de disco, processador, configuração de software e etc.
- Pode ocorrer de o gargalo ser no cliente ou na infra-estrutura. Nunca descarte esta opção.
Quando cito o cliente como um ponto de lentidão quero dizer como situações onde ele não tem capacidade de demandar serviço rápido o suficiente para utilizar todo o recurso disponível no servidor onde se encontra o banco de dados. - Um computador sempre irá funcionar a 100% de velocidade, exceto se algo (hardware,software) propositalmente ou por algum outro motivo não deixe isto acontecer.
Itens para serem monitorado e verificados
Hardware
- Disco, storage, rede SAN (Storage_area_network)
-
Se você utiliza storage:
- alterações em sua configuração de RAID
- Problemas de discos onde algum disco de spare mais lento tenha assumido
- configuração de cache/mirror de cache/balanceamento das controladoras
- Problemas de bateria de controladoras (normalmente desativam automaticamente o cache de gravação)
- Problemas em sua HBA (Host_Bus_Adapter)
- Paths secundários que façam balanceamento na comunicação com o storage.
- Possíveis problemas com fibras óticas.
- CPU
- Processadores sobrecarregados onde os processo estejam sendo enfileirados.
- Processamento aguardando por I/O
- Processamento aguardando por chamadas de sistema
- Processos com afinidade para apenas alguns processadores, gerando gargalos neles.
- Rede
- Problemas de pacotes perdidos ou com erros de checksum
- Problema com placa de rede
- Serviços de DNS problematicos ou mal configurados.
Software
- Sistema Operacional
- Garantia de que não está sendo realizado SWAP da memória utilizada pelo banco de dados.
- Se utilizado file system para salvar os chunks do banco, garantir de que não esteja utilizando um file system com Journaling (Journaling_file_system)
- Verificar se está ocorrendo problemas de AGING nos processos do banco. AGING é uma lógica aplicada a praticamente todos os SO unix onde com o passar do tempo ele baixa a prioridade de execução de processos que estão executando a muito tempo.
- Verificar se os parâmetros de Kernel recomendados foram definidos.
- Instalado novos Patchs no SO.
- Informix
- Se utilizado acesso RAW aos discos, verificar se este está com as configurações corretas para utilização.
- Ler o Machine Notes da versão para o SO utilizado, nele há especificações de Patchs , Kernel e configurações especificas.
- Identificar todas as sessões utilizadas no banco de dados e verificar as estatísticas gerais de cada uma: Leitura/gravação de disco, utilização de memória, utilização de CPU, utilização da comunicação de rede.
- Verificar se tem ocorrido travamentos de usuários (locks) muitos frequentes
- Verificar se está ocorrendo falta de memória para os dados
- Verificar contenção (spin) nos locks internos do banco (mutex/latches)
- Identificar se o problema está em uma funcionalidade de seu sistema, se sim, analisar o trabalho do otimizador SQL com SET EXPLAIN.
- Garantir que a execução do UPDATE STATISTICS estejam em dia e sendo executados conforme as recomendações da IBM.
- Verificar se os serviços de backup podem estar afetando a performance (concorrendo na utilização de memória e I/O)
- Verificar se as fragmentações de tabelas por expressão estão funcionando de acordo como o esperado.
- Gargalos de acessos a chunks/dbspaces
- Se a alocação de índices e extents das tabelas estão otimizados
- Se utilizado muita inclusão de dados, otimização de comunicação e gravação dos dados no banco.
- As areas temporárias estão sendo utilizadas adequadamente
- Se utilizado ambientes em cluster (HDR,RSS,SDS) verificar se estes não estão afetando a performance
- Se utilizado ER (Enterprise Replication) verificar se este não está afetando a performance
- Utilização sem controle do recurso de paralelismo (PDQ).
- Configurações de conectividades: quantidade de Virtual Processos, protocolo, buffers, otimizações de cursores e etc.
- Configurações de caches: Virtual Processor, Dicionário de dados, Distribuição de dados (update statistics) e Stored Procedures
- Levantamento de possibilidade de BUGs no Informix.
- Tunning e configuração do BTREE CLEANER (limpeza e otimização dos índices)
- Problemas de fragmentação na alocação de segmentos de memória
- Ocorrências de blocking Checkpoints muito longo (Flushs de discos)
- Ocorrências de sequencial scans (leitura de uma tabela seqüencialmente)
Comandos
Hardware e Sistema Operacional
Para levantamento e analise de informações de hardware e sistema operacional é necessário ter conhecimento nesta área.
Para ambientes Linux/Unix, como referência recomendo este site: http://bhami.com/rosetta.html
Informix
Para analise e monitoração no Informix, é necessário ter conhecimento de seus comandos, grande parte são no onstat , mas é possível realizar certos levantamentos através de ferramenta como o OAT (Open Admin Tools) e através de acesso a tabelas do SMI (System Monitoring Interface - sysmaster).
Recomendação
Se você está passando por problemas, primeiramente faça um levantamento de alterações em sua infra-estrutura e softwares (atualização de versões e etc).
Converse com seu administrador da maquina, rede e storage sobre alterações ou possíveis problemas que pode ter ocorrido em seu ambiente.
Se ainda assim a desconfiança ficar para o lado do Banco de dados, estude os comandos de monitoração do Informix ou contrate um consultor capacitado.
Alguns links
Estes links são do blog do Vagner pontes que considero relacionado a situações de problema de performance. Estes artigos tratam especificamente sobre Informix:
- Artigo sobre contenções das travas internas do banco, para controle entre as threads.
Mutex Contention - Parte I - Artigo sobre como debugar a conexão entre o cliente/servidor, útil para situações que é preciso identificar algum problema de performance entre a aplicação e o servidor.
Usando SQLIDEBUG/SQLIPRINT - Para problemas com tunning de SELECTs, normalmente utilizamos diretivas para avaliar novos meios de otimização, este artigo irá lhe ajudar para estas situações.
Otimizando Queries com Diretivas - No Informix podemos utilizar o recurso de Alter in-place o que pode facilitar muito em alterações de estrutura de grandes tabelas, mas com o passar do tempo e muitas alterações estas modificações podem afetar a performance de acesso e gravação aos dados.
Alter In-place
- 2660 leituras
Tags:
