Na última postagem, agendamos a coleta de métricas de desempenho durante 24 horas usando pButtons. Nesta postagem, vamos ver algumas métricas essenciais que estão sendo coletadas e como elas estão ligadas ao hardware do sistema. Também começaremos a explorar a ligação entre as métricas do Caché (ou de qualquer plataforma de dados InterSystems) e as métricas do sistema. Além disso, veremos como você pode usar essas métricas para entender a integridade diária de seus sistemas e diagnosticar problemas no desempenho.

Grupos alimentares de hardware

Como você verá a medida que avançarmos por esta série de postagens, os componentes do servidor que afetam o desempenho podem ser categorizados como:

• CPU
• Memória
• E/S de armazenamento
• E/S de rede

Se algum desses componentes estiver sobrecarregado, o desempenho do sistema e a experiência do usuário serão prejudicados. Todos esses componentes estão inter-relacionados, e mudanças em um deles pode afetar os outros, às vezes com consequências inesperadas. Já vi um caso em que corrigir um problema de gargalo de E/S em uma matriz de armazenamento fez o uso de CPU subir para 100%, e a consequência foi uma experiência do usuário ainda pior, pois o sistema ficou livre de repente para fazer mais trabalho, mas não tinha os recursos de CPU necessários devido ao aumento da atividade e taxa de transferência dos usuários.

Também veremos como a atividade do sistema do Caché tem impacto direto nos componentes do sistema. Se houver recursos de E/S de armazenamento limitados, uma mudança positiva que pode ser feita é o aumento da memória do sistema e o aumento da memória dos buffers globais do Caché, o que pode diminuir a E/S de leitura de armazenamento do sistema (mas talvez aumente o uso de CPU!).

Uma das métricas de sistema mais óbvias que deve ser monitorada regularmente ou verificada se os usuários relatarem problemas é o uso de CPU. Pode-se verificar utilizando o top ou nmon no Linux e AIX, ou Monitor de Desempenho do Windows. Como a maioria dos administradores de sistema verificam os dados de CPU regularmente, ainda mais quando são apresentados em gráficos, uma olhada rápida fornece uma boa compreensão da integridade atual do sistema: o que está normal, ou um surto repentino de atividade, que pode ser anormal ou indicar um problema. Nesta postagem, vamos dar uma olhada rápida nas métricas de CPU, mas nos concentraremos nas métricas do Caché. Começaremos verificando os dados do mgstat e como ver os dados em gráficos pode dar uma boa compreensão da integridade do sistema rapidamente.

Introdução ao mgstat

O mgstat é um dos comandos do Caché incluídos e executados no pButtons. O mgstat é uma ferramenta excelente para coletar métricas básicas de desempenho para ajudar a entender a integridade dos sistemas. Veremos os dados do mgstat coletados durante 24 horas em um pButtons, mas, se você quiser capturar dados além do pButtons, o mgstat também pode ser executado sob demanda de forma interativa ou como um trabalho em segundo plano pelo terminal do Caché.

Para executar o mgstat sob demanda pelo namespace %SYS, o formato geral é:

do mgstat(sample_time,number_of_samples,"/caminho_do_arquivo/arquivo.csv",page_length)

Por exemplo, veja abaixo o comando para executar em uma tarefa em segundo plano por uma hora com um período de amostragem de 5 segundos e salvar a saída em um arquivo csv:

job ^mgstat(5,720,"/data/mgstat_data_e_hora_de_hoje.csv")

Por exemplo, para exibir na tela sem algumas colunas, chame a rotina através do label dsp132: Deixarei como tarefa para vocês a verificação da saída para que vocês entendam melhor a diferença.

do dsp132^mgstat(5,720,"",60)

As informações detalhadas das colunas do mgstat estão disponíveis no Guia de monitoramento do Caché na documentação mais recente do Caché: Documentação online da InterSystems

Sobre os dados do mgstat

O pButtons agrupa os dados em um único arquivo HTML, facilitando a navegação e empacotando os dados para envio aos especialistas de suporte da Central de Suporte (WRC) para diagnosticar problemas no desempenho. Entretanto, quando você executa o pButtons por conta própria e deseja exibir os dados em gráficos, eles podem ser separados novamente em um arquivo csv para processamento em gráficos, por exemplo, com o Excel, usando um script de linha de comando ou apenas cortando e colando os dados.

Nesta postagem analisaremos algumas métricas do mgstat para mostrar como somente uma visão rápida dos dados pode indicar se o sistema está com bom desempenho ou se há problemas atuais ou potenciais que afetarão a experiência do usuário.

Glorefs e CPU

O gráfico abaixo mostra o uso de CPU do servidor de banco de dados em um local que executa uma aplicação de hospital com uma alta taxa de transações. Note o pico de atividade durante a manhã, quando há vários ambulatórios, com uma queda durante o almoço, diminuindo então à tarde e à noite. Neste caso, os dados vêm de _(Total)% Tempo do Processador do Monitor de Desempenho do Windows. O formato do gráfico corresponde ao perfil diário de trabalho, sem picos ou depressões incomuns, o que é normal para esse local. Fazendo o mesmo em seu local, você pode começar a estabelecer uma linha de base do que é "normal". Um grande pico, especialmente um de longa duração, pode ser um indicador de problema. Uma postagem futura se concentrará na CPU.

Como referência, este banco de dados está em um servidor Dell R720 com dois processadores E5-2670 de 8 núcleos. O servidor tem 128 GB de memória e 48 GB de buffers de globais.

O próximo gráfico mostra mais dados do mgstat: Glorefs (referências globais) ou acessos ao banco de dados no mesmo dia que o gráfico de CPU. As glorefs indicam a quantidade de trabalho ocorrendo durante a carga de trabalho atual. Embora as referências a globais consumam tempo de CPU, nem sempre elas consomem outros recursos do sistema, como leituras físicas, devido à maneira como o Caché usa o pool global de buffers de memória.

Nas aplicações típicas do Caché, há uma correlação muito forte entre as glorefs e o uso de CPU.

Outro modo de olhar esses dados de CPU e glorefs é dizendo que a redução das glorefs reduz o uso de CPU, permitindo a implantação em servidores com menos núcleos ou a escalabilidade de sistemas existentes. É possível reduzir as referências globais tornando uma aplicação mais eficiente. Voltaremos a esse conceito em postagens futuras.

PhyRds e Rdratio

O formato da representação gráfica dos dados PhyRds (leituras físicas) e Rdratio (proporção de leituras) do mgstat também pode fornecer informações do que se esperar do desempenho do sistema e ajudar a planejar a capacidade. Vamos analisar com mais detalhes a E/S de armazenamento no Caché em postagens futuras.

PhyRds são simplesmente Operações de Entrada e Saída por Segundo (IOPS) de leitura nos bancos de dados do Caché. Você deverá ver os mesmos valores nas métricas do sistema operacional para discos lógicos e físicos. Lembre-se de que, ao verificar as Operações de Entrada e Saída por Segundo (IOPS) do sistema operacional, também podem estar sendo exibidos dados de outras aplicações que não o Caché. Dimensionar o armazenamento sem levar em conta as Operações de Entrada e Saída por Segundo (IOPS) esperadas é uma receita para o desastre. Você precisa saber as IOPS de seu sistema em horários de pico para planejar a capacidade corretamente. O gráfico abaixo mostra PhyRds entre meia-noite e 15h30.

Observe o grande salto de leituras entre 5h30 e 10h. Também há picos menores às 11h e um pouco antes das 14h. Qual você acha que é a causa desses picos? Você também vê esse tipo de picos em seus servidores?

Rdratio é um pouco mais interessante: é a proporção de leituras de blocos lógicos em comparação a leituras de blocos físicos. Portanto, é a proporção de quantas leituras são de buffers de globais (lógicos) da memória e quantas são do disco, que são algumas ordens de grandeza mais lentas. Uma Rdratio alta é uma boa coisa, e chegar perto de zero por longos períodos não é bom.

Observe que, quando as leituras físicas estão altas, Rdratio cai para perto de zero. Nesse local, me pediram para investigar quando o departamento de TI começou a receber ligações de usuários informando que o sistema estava lento por longos períodos. Isso estava acontecendo de maneira aparentemente aleatória durante várias semanas quando me pediram para verificar o sistema.

_Como o pButtons havia sido agendado para execução diária de 24 horas, foi relativamente simples analisar os dados de várias semanas passadas para começar a ver um padrão de PhyRds alta e Rdratio baixa, com uma correlação com as ligações de suporte.*

Após uma análise mais detalhada, descobriu-se que a causa era um novo funcionário que executava diversos relatórios com parâmetros ruins, além de consultas mal escritas sem índices apropriados, o que causava muitas leituras no banco de dados. Essa era a causa da lentidão aparentemente aleatória. Como esses relatórios de longa execução lêem dados dos buffers de globais, a consequência é que os dados interativos dos usuários estavam sendo obtidos do armazenamento físico, em vez da memória, e o armazenamento estava sendo sobrecarregado para atender às solicitações de leitura.

O monitoramento das métricas PhyRds e Rdratio dará uma ideia da integridade de seus sistemas e talvez permitirá que você descubra relatórios ou consultas ruins. Pode haver um motivo válido para uma PhyRds alta: talvez um relatório precise ser executado em determinada hora. Com os sistemas operacionais modernos de 64 bits e servidores com alta capacidade de memória física, você deverá conseguir minimizar a PhyRds em seus sistemas de produção.

Caso a PhyRds esteja alta em seu sistema, você pode considerar algumas estratégias: - Melhorar o desempenho aumentando o número de buffers (globais) de banco de dados (e a memória do sistema). - Relatórios ou extrações de longa duração podem ser feitos fora do horário comercial. - Relatórios somente leitura de longa duração, trabalhos em lote ou extrações de dados podem ser feitos em um servidor Shadow ou um membro de espelhamento assíncrono para minimizar o impacto nos usuários interativos e para diminuir a carga de recursos do sistema, como CPU e Operações de Entrada e Saída por Segundo (IOPS).

Geralmente, é bom ter uma PhyRds baixa, e é nossa meta ao dimensionar os sistemas. Entretanto, se a PhyRds estiver baixa e os usuários estiverem reclamando do desempenho, você pode verificar outros fatores para confirmar que o armazenamento não é o gargalo. A quantidade de leituras pode estar baixa porque o sistema não consegue mais atender à demanda. Veremos o armazenamento com mais detalhas em uma postagem futura.

Resumo

Nesta postagem, verificamos como olhar graficamente as métricas coletadas no pButtons pode fornecer uma compreensão da integridade rapidamente. Em postagens futuras, analisarei com mais detalhes a ligação entre as métricas de sistema e do Caché e como você pode usá-las para se planejar para o futuro.

Sua aplicação está implantada e tudo está funcionando bem. Ótimo, bate aqui! Então, do nada, o telefone começa a tocar sem parar – são os usuários reclamando que, às vezes, a aplicação está "lenta". Mas o que isso significa? Às vezes? Quais ferramentas você tem e quais estatísticas você deve examinar para encontrar e resolver essa lentidão? A infraestrutura do seu sistema está à altura da tarefa de carga do usuário? Que perguntas de design de infraestrutura você deveria ter feito antes de entrar em produção? Como você pode planejar a capacidade de um novo hardware com confiança sem excesso de especificações? Como você pode parar o telefone de tocar? Como você poderia ter impedido o telefone de tocar em primeiro lugar?

Veja aqui uma lista das outras postagens desta série

Esta será uma jornada

Este é a primeira postagem de uma série que explorará as ferramentas e métricas disponíveis para monitorar, revisar e solucionar problemas de desempenho de sistemas, bem como considerações de design e arquitetura de sistema que afetam o desempenho. Ao longo do caminho, iremos percorrer algumas trilhas para entender o desempenho do Caché, sistemas operacionais, hardware, virtualização e outras áreas que se tornam tópicos a partir de seu feedback nos comentários.

Seguiremos o ciclo de feedback fornecido pelos dados de desempenho para visualizar as vantagens e limitações das aplicações e da infraestrutura implantadas e, em seguida, voltar para uma melhor concepção e planejamento de capacidade.

Não é preciso dizer que você deve revisar as métricas de desempenho constantemente. É lamentável o número de vezes que os clientes são surpreendidos por problemas de desempenho que estavam visíveis por um longo tempo, se eles tivessem olhando os dados. Mas, é claro, que a questão é: quais dados? Começaremos a jornada coletando algumas métricas básicas do Caché e do sistema para que possamos ter uma ideia da integridade do seus sistema atual. Em postagens posteriores, mergulharemos no significado das principais métricas.

Há muitas opções disponíveis para o monitoramento do sistema – internamente do Caché e externamente. Vamos explorar um monte deles nesta série. 

Para começar, veremos minha ferramenta favorita para coleta contínua de dados que já está instalada em todos os sistemas Caché – o ^pButtons.

Para ter certeza de que você tem a última cópia do pButtons, reveja a seguinte postagem:

https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-how-update-pbuttons

Coletando métricas de desempenho do sistema – ^pButtons

O utilitário Caché pButtons gera um relatório de desempenho em HTML legível a partir dos arquivos de log que ele cria. A saída das métricas de desempenho pelo pButtons pode ser facilmente extraída, mapeada e revisada. 

Os dados coletados no arquivo HTML pelo pButtons incluem:

• Configuração do Caché: com configuração, mapeamentos de unidades, etc.
• mgstat: Métricas de desempenho do Caché – a maioria dos valores são médios por segundo.
• Unix: vmstat e iostat – recursos do sistema operacional e métricas de desempenho.
• Windows: monitor de desempenho – recursos do Windows e métricas de desempenho.
• Outras métricas que serão úteis.

A coleta de dados do pButtons tem muito pouco impacto no desempenho do sistema, as métricas já estão sendo coletadas pelo sistema, o pButtons simplesmente as empacota para facilitar o arquivamento e transporte. 

Para manter uma linha de base, para análise de tendências e solução de problemas, é uma boa prática realizar uma coleta com o pButtons de 24 horas (meia-noite à meia-noite) todos os dias, para um ciclo de negócios completo. Um ciclo de negócios pode durar um mês ou mais, por exemplo, para capturar dados de processamento no final do mês. Se você não tiver nenhum outro monitoramento de desempenho externo ou coleta, você pode executar o pButtons durante o ano todo. 

Os seguintes pontos-chave devem ser observados:

• Mude o diretório de log para um local longe dos dados de produção para armazenar arquivos de saída acumulados e evitar problemas de disco cheio!
• Execute um script do sistema operacional ou compacte e arquive o arquivo pButtons regularmente. Isso é especialmente importante no Windows, pois os arquivos podem ser grandes.
• Revise os dados regularmente!

No caso de um problema que necessite de análise imediata, os dados do pButtons podem ser visualizados (coletados imediatamente) enquanto as métricas continuam a ser armazenadas para a coleta no final dos dias de execução.

Para obter mais informações sobre pButtons, incluindo visualização, interrupção de uma execução e adição de coleta de dados personalizados, veja o Guia de Monitoramento Caché na documentação mais recente do  Caché: 

http://docs.intersystems.com

Os dados do arquivo HTML pButtons podem ser separados e extraídos (para arquivos CSV, por exemplo) para processamento em gráficos ou outra análise por script ou simplesmente recortar e colar. Veremos exemplos da saída em gráficos posteriormente na próxima postagem.

É claro que, se você tiver problemas urgentes de desempenho, entre em contato com a Central de Suporte (WRC).

Agende a coleta de dados de 24 horas do pButtons

O ^pButtons pode ser iniciado manualmente a partir do prompt do terminal ou agendado. Para agendar uma coleta diária de 24 horas:

1. Inicie o terminal Caché, mude para o %SYS namespace e execute o pButtons manualmente uma vez para configurar as estruturas de arquivo do pButtons:

   %SYS>d ^pButtons Current log directory: /db/backup/benchout/pButtonsOut/ Available profiles: 1 12hours - 12 hour run sampling every 10 seconds 2 24hours - 24 hour run sampling every 10 seconds 3 30mins - 30 minute run sampling every 1 second 4 4hours - 4 hour run sampling every 5 seconds 5 8hours - 8 hour run sampling every 10 seconds 6 test - A 5 minute TEST run sampling every 30 seconds

Selecione a opção 6. para teste, amostragem de execução de TESTE de 5 minutos a cada 30 segundos. Observe que sua numeração pode ser diferente, mas o teste deve ser óbvio.

Durante a execução, execute Collect^pButtons (conforme mostrado abaixo), você verá informações incluindo o runid. Neste caso, “20160303_1851_test”.

%SYS>d Collect^pButtons
Current Performance runs:
    <strong>20160303_1851_test</strong>        ready in 6 minutes 48 seconds nothing available to collect at the moment.
%SYS>

Observou que esta execução de 5 minutos leva 6 minutos e 48 segundos para finalizar? O pButtons adiciona um período de carência de 2 minutos a todas as execuções permitindo um tempo para a coleta e ordenação dos logs no formato HTML. 

2. IMPORTANTE! Altere o diretório de saída do log pButtons - o local de saída padrão é a pasta /mgr. Por exemplo, no Unix, o caminho para o diretório de log pode ser assim:

do setlogdir^pButtons("/algum_lugar_com_muito_espaço/perflogs/")

Certifique-se de que o Caché tenha permissões de gravação para o diretório e que haja espaço em disco suficiente disponível para acumular os arquivos de saída.

3. Crie um novo perfil de 24 horas com intervalos de 30 segundos executando o seguinte:

write $$addprofile^pButtons("<strong>My_24hours_30sec</strong>","24 hours 30 sec interval",30,2880)

Verifique se o perfil foi adicionado ao pButtons:

%SYS>d ^pButtons
Current log directory: /db/backup/benchout/pButtonsOut/
Available profiles:
     1  12hours     - 12 hour run sampling every 10 seconds
     2  24hours     - 24 hour run sampling every 10 seconds
     3  30mins      - 30 minute run sampling every 1 second
     4  4hours      - 4 hour run sampling every 5 seconds
     5  8hours      - 8 hour run sampling every 10 seconds
     6  My_24hours_30sec- 24 hours 30 sec interval
     7  test        - A 5 minute TEST run sampling every 30 seconds

select profile number to run:

4. Dica Para sites UNIX, revise o comando disk. Os parâmetros padrão usados com o comando 'iostat' podem não incluir os tempos de resposta do disco. Primeiro exiba quais comandos de disco estão configurados atualmente:

%SYS>zw ^pButtons("cmds","disk")
^pButtons("cmds","disk")=2
^pButtons("cmds","disk",1)=$lb("iostat","iostat ","interval"," ","count"," > ")
^pButtons("cmds","disk",2)=$lb("sar -d","sar -d ","interval"," ","count"," > ")

Para coletar estatísticas de disco, use o comando apropriado para editar a sintaxe de sua instalação do UNIX. Observe o espaço à direita. Aqui estão alguns exemplos:

LINUX:     set $li(^pButtons("cmds","disk",1),2)="iostat -xt "
AIX:       set $li(^pButtons("cmds","disk",1),2)="iostat -sadD "
VxFS:      set ^pButtons("cmds","disk",3)=$lb("vxstat","vxstat -g DISKGROUP -i ","interval"," -c ","count"," > ")

Você pode criar arquivos HTML pButtons muito grandes, executando os comandos iostat e sar. Para avaliações regulares de desempenho, geralmente uso apenas o iostat. Para configurá-lo há apenas um comando:

set ^pButtons("cmds","disk")=1

Mais detalhes sobre como configurar pButtons estão na documentação on-line.

5. Programe o pButtons para iniciar à meia-noite no Portal de Gerenciamento > Operação de Sistema > Gerenciado de Tarefas:

Namespace: %SYS
 Task Type: RunLegacyTask
 ExecuteCode: Do run^pButtons("My_24hours_30sec")
 Task Priority: Normal
 User: superuser
 How often: Once daily at 00:00:01

Coletando dados com pButtons

O pButtons disponível em versões mais recentes das Plataformas de Dados InterSystems incluem a coleta automática. Para coletar e ordenar manualmente os dados em um arquivo HTML no %SYS namespace, execute o seguinte comando para gerar quaisquer arquivos de saída HTML pButtons pendentes:

do Collect^pButtons

O arquivo HTML estará no logdir que você configurou no passo 2 (se você não configurou, vá e faça agora!). Caso contrário, o local padrão é <Caché install dir/mgr> <Caché install dir/mgr>

Os arquivos são nomeados como <hostname_instance_Name_date_time_profileName.html><hostname_instance_Name_date_time_profileName.html> Ex. vsan-tc-db1_H2015_20160218_0255_test.html

Considerações sobre o Monitor de Desempenho do Windows

Se o sistema operacional for Windows, o Monitor de Desempenho do Windows (perfmon) pode ser usado para coletar dados em sincronia com as outras métricas coletadas. Em distribuições Caché mais antigas do pButtons, o perfmon do Windows precisa ser configurado manualmente. Se houver uma demanda nos comentários da postagem, escreverei uma postagem sobre a criação de um template perfmon para definir os contadores de desempenho a serem monitorados e agendar a execução para o mesmo período e intervalo que o pButtons.

Resumo

Esta postagem nos fez começar a coletar alguns dados para analisar. No final da semana, começarei a examinar alguns dados de amostra e o que isso significa. Você pode acompanhar os dados coletados em seus próprios sistemas. Vejo você então.

http://docs.intersystems.com