IBAnalyst: o que você pode ver na Visão Resumida

Dmitry Kuzmenko, última atualização 31-03-2014

Resumo

Este documento é dedicado à explicação das informações na página “Visão de resumo” do IBAnalyst e como interpretar essas informações para suas próprias estatísticas de banco de dados. Também adicionamos vários exemplos de estatísticas ao pacote de instalação para facilitar o estudo de todos os detalhes das estatísticas do InterBase. Eles estão no diretório Examples da instalação do IBAnalyst.

Se você não sabe o que é transação mais antiga, snapshot mais antigo, ativa e próxima, leia antes o artigo de Craig Stunz “Understanding Transactions Lifetime”:

http://blogs.teamb.com/craigstuntz/articles/UnderstandingTransactionLifetimes.aspx

Números de transações

Se você leu o artigo Understanding Transaction Lifetimes, talvez ainda tenha perguntas sobre os números OIT/OST/OAT. Aqui está uma breve descrição:


Número	Mantém-se, …	Avança, …
Transação mais antiga	quando uma transação com esse número foi revertida e havia muitos dados alterados nela, ou quando a conexão do cliente foi perdida	quando a varredura automática ou manual é bem-sucedida.
Snapshot mais antigo	quando um snapshot (ou leitura confirmada com gravação anterior ao IB 7.1) está ativo por um longo tempo (ele lembrava o snapshot ativo mais antigo como seu OST local)	quando uma nova transação inicia, se a transação que mantém o OST termina
Ativa mais antiga	quando uma transação com esse número está ativa por um longo tempo	quando uma nova transação inicia, se a transação que mantém o OAT termina
Próxima	nunca	quando uma nova transação inicia

nota: Transação mais antiga aqui é o mesmo que Transação Interessante Mais Antiga (OIT), mencionada em muitos outros artigos.

Estatísticas finas com configurações padrão

Vamos iniciar o IBAnalyst e abrir (com o menu Statistics/Load statistics from file) o arquivo !allok.txt.

O IBAnalyst relata não apenas a data de criação do banco de dados, mas também reconhece a data/hora atual no servidor se as estatísticas foram obtidas via Services API, ou a data/hora do arquivo se for um arquivo de estatísticas carregado.

É por isso que sugerimos não modificar os arquivos de estatísticas, pois nesse caso o IBAnalyst calculará incorretamente a média de transações por dia. A linha de transações por dia aqui mostra cerca de ~12500 transações por dia e que o banco de dados “vive” desde sua criação ou restauração há 8 dias.

As transações Mais antiga, Snapshot mais antigo, Ativa mais antiga e Próxima estão em estado perfeito aqui; desejamos que você sempre tenha estatísticas assim.

Muitas transações ativas

Em seguida, abra o arquivo !lotofactive.txt (você pode olhar a imagem !allok a qualquer momento para comparar com os exemplos seguintes).

Aqui a linha de transações Ativas está marcada em vermelho, porque há uma grande diferença entre a transação Ativa mais antiga e a Próxima. Isso significa que alguma transação no momento em que as estatísticas foram obtidas ainda estava ativa, e após seu início, 55.000 transações já foram iniciadas (elas podem estar em qualquer estado - ativa, confirmada, revertida). Como a contagem média de transações por dia é de ~12500, o IBAnalyst mostra um aviso de que alguma transação ainda vive há 4,4 dias. Isso pode acontecer quando:

algum aplicativo ainda está em execução e tem pelo menos uma transação aberta - algum usuário talvez mantenha o aplicativo em execução por um longo tempo
o aplicativo executa por um longo tempo e perde os identificadores de transação - ou seja, seu código (ou componentes/bibliotecas que você usa) inicia transações dinamicamente e, sob algumas circunstâncias, “esquece” de finalizá-las com rollback ou commit.
seu aplicativo não usa transações explícitas (BDE), deixando o gerenciamento de transações para os componentes usados. Como resultado, a vida útil das transações não é controlada pelo aplicativo, e você pode ter certeza de que a maioria das transações Próxima-OAT está realmente ativa.
seu aplicativo usa driver ou componentes que permitem “transação padrão”. Se seu código não controla essa transação, ela pode durar muito tempo.

Infelizmente, as estatísticas não mostram o número real de transações atualmente ativas. Isso só pode ser visualizado no InterBase 7.x usando IBConsole, IB Performance Monitor ou por consulta direta à tabela temporária do sistema tmp$transactions. No Firebird 1.5, você pode chamar isc_database_info com o parâmetro isc_info_active_transactions.

Varredura

Agora vamos abrir o arquivo !needsweep.txt.

A varredura é um processo de manutenção dentro do InterBase. A varredura percorre todos os registros no banco de dados e tenta limpar todas as versões de lixo, e então tenta avançar o número da transação mais antiga. Em um banco de dados recém-criado, o intervalo de varredura padrão é 20000. Quando a diferença entre transações (veja a tabela abaixo) se torna maior que o intervalo de varredura, a varredura será executada automaticamente. Assim, você pode ver degradação periódica de desempenho no seu banco de dados. Por exemplo, seus aplicativos funcionam bem durante segunda e terça, mas na quarta os usuários relatam problemas de desempenho por algumas horas, e então o desempenho volta ao normal.

Se você vê comportamento semelhante - é uma varredura automática.


Versão do servidor	Quando a varredura é executada
InterBase 7.x	(Ativa mais antiga - Mais antiga) > Intervalo de varredura
InterBase 4.x, 5.x, 6.x, Firebird anterior a 1.5.2, Yaffil	(Snapshot mais antigo - Mais antiga) > Intervalo de varredura

Tabela 1. Condições para execução automática da varredura

nota: O IBAnalyst mostra automaticamente as informações corretas de intervalo de varredura para todas as versões. O IBAnalyst pode detectar a diferença entre implementações de servidor apenas pelo ID ODS, por exemplo, InterBase 7.x tem ODS 11.x, outros servidores modernos têm ODS 10.x. Se você trabalha apenas com bancos de dados InterBase 7.x (ODS 11), pode ativar a opção apropriada na caixa de diálogo Options.

Quando seu banco de dados tem intervalo de varredura <> 0, o IBAnalyst basicamente marca essa linha em amarelo (avisando que a varredura automática pode iniciar a qualquer momento imprevisível). Geralmente, 60% de todos os aplicativos têm problemas com varredura automática. A maneira mais fácil de evitar esse problema é definir o intervalo de varredura como 0, o que desativa a varredura automática. Mas, se algum aplicativo fizer muitas alterações e depois reverter, a transação mais antiga congelará e não avançará até que a varredura seja executada. Como o estado efetivo das transações é calculado da Mais antiga até a Próxima, essa distância crescerá e o desempenho cairá. Para evitar isso, você deve executar a varredura manualmente (gfix -sweep). Nesta imagem, você pode ver o comportamento quando o intervalo de varredura é 0 e houve uma grande transação revertida:

Aqui o valor do intervalo de varredura mostra que alguma transação grande (com muitas alterações) foi revertida há cerca de 4,5 dias. Recomendamos executar a varredura manualmente todos os dias.

Claro, para os mencionados 60% dos aplicativos, talvez seja melhor definir o intervalo de varredura maior ou menor que 20000, mas isso depende de muitos fatores (transações diárias é um desses fatores, por exemplo) e só pode ser entendido de forma experimental. Então, se você definir o intervalo de varredura como 0, pode ter certeza de que a varredura não será executada automaticamente em um momento imprevisível.

A mesma imagem você pode ver para o arquivo !rollback.txt.

nota: Se a varredura está sendo executada automaticamente, para um banco de dados grande ou com muitas versões de registros de lixo, as transações Snapshot, Ativa e Próxima podem avançar enquanto a varredura trabalha, e a varredura pode iniciar novamente no início da transação mais próxima.

Quando a varredura não consegue fazer seu trabalho

Há muitos casos em que a varredura não consegue avançar a transação mais antiga. Claro, a varredura primeiro tenta fazer seu trabalho, ou seja, verificar todos os registros no banco de dados e coletar versões de registros desnecessárias. Mas ela será executada repetidamente sem sucesso se

houve algum problema quando a varredura foi executada: o servidor foi interrompido durante a varredura, ou houve erro durante a limpeza das versões de registros de lixo. Além disso, você pode ver essa imagem quando:

as estatísticas foram obtidas enquanto a varredura trabalhava
a varredura está em execução e tentando coletar lixo para uma tabela que está sendo atualizada constantemente. Isso pode durar até que as atualizações terminem.
a varredura está parada em bloqueios de página, porque há muitos usuários trabalhando com os dados.

Em geral, a varredura não tem chances de terminar durante alta carga no banco de dados. Normalmente, quando o desempenho degrada a ponto de impossibilitar o trabalho normal, o DBA reinicia o servidor, e a varredura é executada na primeira conexão do usuário. Como haverá algum tempo enquanto outros usuários se conectam, a varredura terá tempo de terminar seu trabalho.

Como o InterBase 7.1/7.5 calcula o intervalo de varredura de forma diferente das versões anteriores, a outra situação em que a varredura não consegue fazer seu trabalho é quando algum aplicativo tem uma transação de snapshot de longa duração:

Aqui há dois avisos - um (amarelo) sobre snapshot de longa duração, e outro (vermelho) sobre o intervalo de varredura e o intervalo de varredura atual.

Snapshot de longa duração

A imagem anterior indica um snapshot de longa duração no InterBase 7.1/7.5. Se o intervalo de varredura fosse definido como 0, não haveria avisos vermelhos, apenas amarelos. Uma imagem semelhante indicará uma transação de snapshot de longa duração em outras versões do InterBase, Firebird e Yaffil:

Como você vê aqui, o intervalo de varredura é calculado pela diferença entre o Snapshot mais antigo e a transação mais antiga (para ODS 10, versões pré-IB7.x). Portanto, não há aviso de varredura (exceto o intervalo de varredura padrão).

Mas, não são apenas transações de snapshot que afetam o estado das transações dessa forma. Todas as versões do InterBase, Firebird e Yaffil, exceto InterBase 7.1/7.5, têm o seguinte comportamento, que chamamos de “artefato de leitura confirmada”.

Snapshots novamente e Quando ReadCommitted congela o Snapshot mais antigo

Abra o arquivo !snapshot2.txt:

Observe que a transação mais antiga é maior que o snapshot mais antigo. E o intervalo de varredura tem valor negativo. Isso pode acontecer em dois casos. O primeiro caso é quando há algumas transações de snapshot iniciando e confirmando uma após a outra. Ou seja, essa imagem pode acontecer com snapshots, assim como a imagem anterior. O próximo caso acontece apenas em servidores diferentes de IB 7.1/7.5 com transações ReadCommitted (ou em combinação de transações ReadCommitted e Snapshot). Elas podem travar o número do Snapshot mais antigo da mesma forma que transações Snapshot fazem. O estado atual das transações pode ser emulado com a seguinte sequência:

iniciar transação 1, snapshot ou read_committed
iniciar/confirmar algumas transações read_committed
iniciar transação 2, snapshot ou read_committed
iniciar/confirmar algumas transações read_committed
confirmar transação 1

(claro, falamos aqui de transações read_committed com gravação, não somente leitura).

Neste ponto, a transação 2 atualmente ativa (snapshot ou read committed), iniciada após o snapshot 1 (marca 3), manterá o número de snapshots como Snapshot mais antigo (se você trabalha com IB 7.1/7.5, isso só pode acontecer para transações snapshot concorrentes. read_committed ou read_committed+snapshot não produzirão esse efeito). Como não houve grandes reversões, a transação mais antiga avança e se torna maior que o Snapshot mais antigo.

Agora, se você tem uma transação read committed de longa duração, verá uma imagem como esta. Infelizmente, você não pode fazer nada aqui com seus aplicativos (exceto adicionar o parâmetro “read” para transações somente leitura). E, claro, a varredura não será executada automaticamente (se definida <> 0) nesse caso.

nota: esse comportamento será corrigido no Firebird 2.0

Visões absoluta e relativa

Por padrão, o IBAnalyst preenche as linhas de transações de acordo com o percentual de seu valor absoluto. Ou seja, 100% é de 0 até a Próxima transação. Às vezes, quando o banco de dados funciona por um longo tempo, você pode ver as informações de transação como

Embora haja muitas transações, a diferença entre snapshot, ativa e mais antiga parece muito pequena (próxima de 98%). Para tornar a situação mais clara, abra a caixa de diálogo Options, aba Transactions, e marque a opção “Relative (from oldest) bars %” (você não pode marcar essa caixa se usar a visão de estilo antigo, sem barras de gráfico). Após pressionar o botão OK, a visão de transações mudará para

Agora você vê a diferença de transações em visão relativa (100% é da transação mais antiga (ou snapshot) para a próxima, não a partir de 0). É mais fácil entender a situação atual e visualizar avisos (se houver).

Esta visão permanecerá até que você a desmarque na caixa de diálogo Opções. Você pode entender qual visão está vendo pela linha Transação mais antiga ou Snapshot mais antigo - na visão relativa, uma dessas linhas nunca é preenchida com cor verde. Na visão absoluta, ela é sempre preenchida (parcialmente, é claro).

Ainda tem dúvidas? Pergunte-nos em [email protected]