onstat–g ath: Mostra informações sobre todos os threads

Utilize o comando onstat –g ath para mostrar informações sobre todos os threads.

Sintaxe:

>> onstat –g ath

Descrição da saída do comando:

tid – ID da thread

tcb – Acesso ao bloco de controle da thread

rstcb – Acesso ao bloco de controle RSAM thread

prty – Prioridade da thread

status – Status da thread

vp-class – Classe do Virtual Processor

name – nome da thread. Para threads que participam em operações de otimização de armazenamento paralelo, o nome da operação e o numero do thread.

• compress.number = A thread esta compactando dados
• repack.number = A thread esta reempacotando dados
• uncompress.number = A thread esta descompactando dados
• update_ipa.number = A thread esta removendo operações de alterações pendentes

SLES 12–Notas Gerais sobre Tunning do sistema

Estarei postando assim que possível, alguns tópicos sobre Tunning no SLES-12.

O objetivo é discutir como encontrar as razões para problemas de desempenho e fornecer meios para resolver esses problemas. Antes de começar a ajustar o sistema, certifique-se de ter descartado problemas comuns e ter encontrado a causa do problema. Deve-se também ter um plano detalhado sobre como ajustar o sistema, porque a aplicação de dicas de ajuste aleatório muitas vezes não vai ajudar e poderia piorar as coisas.

Abordagem geral ao ajustar um sistema

1. Especifique o problema que precisa ser resolvido;
2. Caso a degradação seja nova, identifique quaisquer alterações recentes no sistema;
3. Identificar por que o problema é considerado um problema de desempenho;
4. Especifique uma métrica que pode ser usada para analisar o desempenho. Essa métrica pode ser, por exemplo, latência, taxa de transferência, o numero máximo de usuários que estão logados simultaneamente ou o numero máximo de usuários ativos;
5. Medir o desempenho atual usando a métrica da etapa anterior;
6. Identificar o subsistema onde o aplicativo esta gastando mais tempo;
7. Monitorar o sistema e/ou o aplicativo, assim como analisar os dados, categorize onde o tempo esta sendo gasto;
8. Ajuste o subsistema identificado na etapa anterior;
9. Reavalie o desempenho atual sem monitoramento usando a mesma métrica como antes;
10. Se o desempenho ainda não for aceitável, volte a etapa 3 novamente.

Esteja Certo que problema resolver

Antes de começar a ajustar um sistema, tente descrever o problema da forma mais exata possível. Uma declaração como “O sistema é lento!” não é uma descrição útil do problema. Por exemplo, poderia fazer uma diferença se a performance do sistema precisa ser melhorada em geral ou apenas em horário de pico.

Além disso, certifique-se de que você pode aplicar uma medição ao seu problema, caso contrario você não será capaz de verificar se o ajuste foi um sucesso ou não . Você deve sempre ser capaz de comparar “antes” e “depois”. Quais métricas usar depende do cenário ou aplicativo que você esta procurando. As métricas de servidor Web relevantes, por exemplo, poderiam ser expressas em termos de:

Latência

o Tempo para entregar uma página.

Taxa de transferência

Numero de paginas atendidas por segundo ou megabytes transferidos por segundo.

Usuários Ativos

O numero máximo de usuários que podem baixar paginas enquanto ainda estão recebendo paginas dentro de uma latência aceitável.

Eliminar problemas comuns

Um problema de desempenho geralmente é causado por problemas de rede ou hardware, bugs ou problemas de configuração. Certifiques-e de descartar problemas como os listados abaixo antes de tentar ajustar seu sistema:

• Analise a saída do systemd journal;
• Analise (usando top ou ps) se um determinado processo se comporta mal por consumir quantidades incomuns de tempo de CPU e memoria.
• Analise se há problemas de rede /proc/net/dev.
• Em caso de problemas de I/O com discos físicos, certifique-se de que ele não é causado por problemas de hardware (verifique o disco com o smartmontools).
• Certifique-se de que os trabalhos em segundo plano estão programados para serem executados em períodos em que a carga do servidor é baixa. Esses trabalhos também devem ser executados com baixa prioridade definida via nice.
• Se o servidor  executar vários serviços utilizando o mesmos recursos, considere mover serviços para outro servidor.
• Por ultimo, verifique se o software está atualizado.

Procurando por gargalos

Encontrar gargalos muitas vezes é a parte mais difícil ao ajustar um sistema. O SuSE Enterprise Server, assim como todos os Linux/Unix, oferece muitas ferramentas para ajuda-lo nessa tarefa. Em posts futuros estarei passando mais informações detalhadas sobre as aplicações gerais de monitoramento do sistema e a analise do arquivo de log. Se o problema requer uma analise longa e profunda, o kernel do Linux oferece meios para realizar essa analise, vou estar abordando esse assunto também futuramente.

Depois de ter coletado os dados, ele precisa ser analisado. Primeiro, verifique se o hardware do servidor (memoria, CPU, barramento) e os I/Os (disco, rede) são suficientes. Se essa condição básica forem atendidas, o sistema poderá se beneficiar de um Tuning.

Passo a passo do Tuning

Certifique-se de planejar cuidadosamente o tuning em si. É de vital importância fazer um passo de cada vez. Só fazendo isso você será capaz de medir se a mudança forneceu uma melhoria ou mesmo teve um impacto negativo. Cada atividade de ajuste deve ser medido durante um período de tempo suficiente para garantir que você possa fazer uma analise com base em dados significativos. Se você não pode medir um efeito positivo, não faça mudança permanente. As possibilidades são, que poderia ter um efeito negativo no futuro.

Variável de ambiente PSORT_NPROCS

A variável de ambiente PSORT_NPROCS permite que o servidor de banco de dados melhore o desempenho sorts de processo paralelo alocando mais threads para classificação.

Antes da classificação do pacote do SORT executar em paralelo, verifique se o servidor de banco de dados tem memória suficiente.

>>-setenv--PSORT_NPROCS--threads-------------------------------><

export PSORT_NPROCS=threads

threads

É um numero inteiro, especifica o número máximo de threads a ser usado para classificar uma consulta. Este valor não pode ser maior que 10.

O comando a seguir define PSORT_NPROCS como 4:

setenv PSORT_NPROCS 4

export PSORT_NPROCS=4

Para desativar o SORT em paralelo, digite o seguinte comando:

unsetenv PSORT_NPROCS

Recomenda-se inicialmente definir PSORT_NPROCS como 2 quando o servidor tiver varias CPUs. Se a atividade subsequente da CPU for menor que a atividade de I/O, então pode-se ir aumentando o valor de PSORT_NPROCS.

Nota

Se a variável de ambiente PDQPRIORITY não estiver definida, o servidor de banco de dados aloca a quantidade mínima de memória para o SORT. Essa memória mínima é insuficiente para iniciar até dois segmentos de SORT. Se não estiver definido o PDQPRIORITY, verificar a memória disponível antes de executar uma ordenação em grande escala (como uma criação de índice) para se certificar de que tem memória suficiente.

Technote (Solução de Problemas)

Problema (Resumo)

Você executa o UPDATE STATISTICS e ele falha com os erros 567 e 179. Os erros indicam e que a instância do IDS não tem dbspace temporário suficiente no disco para os arquivos temporários criados durante o sort. No entanto, o espaço ocupado pela tabela no disco é muito menor do que os dados de classificação relatados pelo plano de consulta.

Sintoma:

O comando UPDATE STATISTICS falha retornando os seguinte erros:

567: Cannot write sorted rows.
179: ISAM error: no free disk space for sort

Causa:

Verifique para determinar se você tem uma coluna ou colunas de tipo de dados VARCHAR. O espaço ocupado por dados VARCHAR no disco em um dbspace regular é apenas o espaço necessário para os dados armazenados, Ou o comprimento mínimo do tipo de dados se ele for declarado. No entanto, os dados são expandidos para seu tamanho máximo quando lidos de tablespace no disco dentro da  memória, e esse tamanho é mantido quando os arquivos de sort temporários são gravados em dbspaces temporários. Por exemplo, uma sequência de dois caracteres em um campo varchar (255) ocupará apenas vários bytes no disco. No entanto, quando os dados são lidos na memória, ele vai ocupar o comprimento do campo completo, neste caso a memória requer 255 bytes para armazenar os dados.

Os dados de ordenação reportados no plano de consulta baseiam-se no comprimento total dos dados. No exemplo que segue, a tabela ocupa 31.9 MB no disco e a instância foi configurada com 80MB de espaço temporário, no entanto o UPDATE STATISTICS falhou com os erros 567 e 179. O otimizador calculou a classificação dos dados em 127.5 MB. A tabela tinha um campo VARCHAR(255) e dois campos CHAR(10). Os comprimentos de sequencia no campo VARCHAR variaram de um a seis bytes, ocupando assim muito menos do que no máximo de 255 bytes no disco.

Table: informix.tab1

Mode: HIGH

Number of Bins:      267     Bin size     5000

Sort data   127.5 MB Sort memory granted    15.0 MB

Estimated number of table scans 3

PASS #1 col1

PASS #2 col2

PASS #3 col3

Resolvendo o problema

• aumentar a memória disponível para o SORT. Isso também deve diminuir o tempo necessário para que as estatísticas de atualização sejam concluídas.
• aumentar o dbspace temporário.
• Altere as estatísticas de atualização para que classifique menos dados.Por exemplo, alterne entre os UPDATE STATISTCS HIGH e UPDATE STATISTICS MEDIUM.
• Diminua o comprimento máximo do tipo de dados VARCHAR.

 

Link de origem: http://www-01.ibm.com/support/docview.wss?uid=swg21358640