Interpretar os resultados de desempenho no AlloyDB Omni em uma VM

Este documento descreve como interpretar os resultados de desempenho no AlloyDB Omni em uma VM. Este documento pressupõe que você já conhece o PostgreSQL.

Quando você cria um gráfico de capacidade ao longo do tempo à medida que outra variável é modificada, normalmente a capacidade aumenta até chegar a um ponto de esgotamento de recursos.

A figura a seguir mostra um gráfico de dimensionamento de throughput típico. À medida que o número de clientes aumenta, a carga de trabalho e o throughput aumentam até que todos os recursos sejam esgotados.

Gráfico de escalonamento de throughput mostrando o throughput para o número de clientes. À medida que o número de clientes aumenta, a taxa de transferência aumenta até que todos os recursos sejam esgotados.
**Figura 1:** uma figura que mostra um gráfico de escalonamento de capacidade típico. À medida que o número de clientes aumenta, a carga de trabalho e a capacidade aumentam até que todos os recursos sejam esgotados.

O ideal é que, ao dobrar a carga no sistema, a capacidade também dobre. Na prática, haverá contenção de recursos que leva a aumentos menores de throughput. Em algum momento, o esgotamento ou a contenção de recursos fará com que a taxa de transferência seja nivelada ou até diminua. Se você está otimizando a capacidade, esse é um ponto-chave a ser identificado, porque ele direciona seus esforços para onde ajustar o aplicativo ou o sistema de banco de dados para melhorar a capacidade.

As razões típicas para a redução ou queda da taxa de transferência incluem:

  • Esgotamento de recursos de CPU no servidor do banco de dados
  • O esgotamento de recursos da CPU no cliente para que o servidor de banco de dados não receba mais trabalho
  • Contenção de bloqueio de banco de dados
  • Tempo de espera de E/S quando os dados excedem o tamanho do pool de buffers do Postgres
  • Tempo de espera de E/S devido à utilização do mecanismo de armazenamento
  • Engulhos de largura de banda da rede ao retornar dados para o cliente

A latência e a capacidade de processamento são inversamente proporcionais. À medida que a latência aumenta, a capacidade diminui. Isso faz sentido intuitivamente. À medida que um gargalo começa a se formar, as operações começam a levar mais tempo e o sistema realiza menos operações por segundo.

Gráfico de escalonamento de latência mostrando que a latência permanece constante até que ocorra fricção devido à disputa de recursos.
Figura 2:mostra um gráfico de escalonamento de latência típico. A latência permanece constante até que ocorra uma fricção devido à disputa de recursos.

O gráfico de dimensionamento de latência mostra como a latência muda à medida que a carga em um sistema aumenta. A latência permanece relativamente constante até que ocorra uma fricção devido à disputa de recursos. O ponto de inflexão dessa curva geralmente corresponde ao achatamento da curva de throughput no gráfico de escalonamento de throughput.

Outra maneira útil de avaliar a latência é como um histograma. Nessa representação, agrupamos as latências em buckets e contamos quantas solicitações se enquadram em cada um deles.

Gráfico de escalonamento de latência mostrando que a latência permanece constante até que ocorra fricção devido à contenção de recursos.
Figura 3:uma figura que mostra um histograma de latência típico. A latência permanece constante até que ocorra uma fricção devido à disputa de recursos.*

Esse histograma de latência mostra que a maioria das solicitações tem menos de 100 milissegundos e latências maiores que 100 milissegundos. Entender a causa das solicitações com latências mais longas pode ajudar a explicar as variações de desempenho do aplicativo. As causas da cauda longa de latências aumentadas correspondem às latências aumentadas observadas no gráfico de escalonamento de latência típico e ao achatamento do gráfico de throughput.

O histograma de latência é mais útil quando há várias modalidades em um aplicativo. Uma modalidade é um conjunto normal de condições operacionais. Por exemplo, na maioria das vezes, o aplicativo acessa páginas que estão no buffer de cache. Na maioria das vezes, o aplicativo está atualizando linhas existentes. No entanto, pode haver vários modos. Às vezes, o aplicativo está recuperando páginas do armazenamento, inserindo novas linhas ou apresentando contenção de bloqueio.

Quando um aplicativo encontra esses diferentes modos de operação ao longo do tempo, o histograma de latência mostra essas várias modalidades.

Gráfico de escalonamento de latência mostrando que a latência permanece constante até que ocorra fricção devido à contenção de recursos.
Figura 4:mostra um histograma de latência bimodal típico. A latência permanece constante até que ocorra uma fricção devido à disputa de recursos.

Esta figura mostra um histograma bimodal típico em que a maioria das solicitações é atendida em menos de 100 milissegundos, mas há outro cluster de solicitações que leva de 401 a 500 milissegundos. Entender a causa dessa segunda modalidade pode ajudar a melhorar o desempenho do seu aplicativo. Também pode haver mais de duas modalidades.

A segunda modalidade pode ser devido a operações normais do banco de dados, infraestrutura e topologia heterogêneas ou comportamento do aplicativo. Confira alguns exemplos:

  • A maioria dos acessos de dados é do pool de buffer do PostgreSQL, mas alguns vêm do armazenamento
  • Diferenças nas latências de rede para alguns clientes no servidor do banco de dados
  • A lógica do aplicativo que executa operações diferentes dependendo da entrada ou do horário do dia
  • Contenção de bloqueio ocasional
  • Picos na atividade do cliente