Insights do Snowflake Postgres¶

Ocorrência no cache¶

Geralmente, o Postgres tenta manter os dados acessados com mais frequência no cache do buffer compartilhado. O índice de ocorrências no cache mede quantas solicitações de conteúdo o cache do buffer pode processar em comparação com a quantidade de solicitações que ele recebe. A ocorrência no cache é uma solicitação processada com sucesso, e o oposto é chamado de falha. A falha ultrapassa o cache e vai para o sistema de arquivos para atender à solicitação.

Portanto, se você tem 100 ocorrências no cache e 2 falhas, seu índice de ocorrências no cache é de 100/102, que é igual a 98%.

Para operações normais do Postgres e desempenho, o índice ideal de ocorrências no cache do Postgres é de cerca de 99%.

Se o índice for abaixo disso, talvez seja necessário mudar para uma instância com mais memória.

Ocorrência no índice¶

Adicionar índices ao banco de dados é fundamental para o desempenho da consulta e do aplicativo. Os índices são particularmente valiosos em tabelas grandes.

A taxa de ocorrência no índice é medida como uma proporção ou porcentagem do número total de consultas ou execuções de consulta que utilizam com sucesso um índice em relação ao número total de consultas executadas. Uma taxa de ocorrência no índice mais alta sugere melhor uso do índice e desempenho geral da consulta.

Em geral, você busca pelo menos 99% em tabelas com mais de 10.000 linhas. Se você tiver uma tabela maior que 10.000 com uso baixo ou nenhum uso do índice, esse será o ponto de partida ideal para adicionar um índice.

Índices não utilizados¶

Índices não utilizados no PostgreSQL são aqueles criados em tabelas, mas que não são usados ativamente. Esses índices consomem espaço em disco, requerem manutenção e podem prejudicar o desempenho.

Veja a seguir alguns motivos pelos quais você deve se preocupar com índices não utilizados no Postgres:

• Armazenamento e espaço em disco: índices não utilizados ocupam espaço em disco que poderia ser mais bem aproveitado para outras finalidades. Isso pode resultar no aumento dos custos de armazenamento e reduzir o espaço disponível para outros objetos de banco de dados.

• Impacto no desempenho: os índices geram uma sobrecarga durante operações de modificação de dados, como inserções, atualizações e exclusões. Quando há muitos índices não utilizados, essas operações demoram mais porque o banco de dados deve atualizar vários índices além da tabela.

• Execução mais lenta de consultas: o otimizador de consultas do Postgres considera todos os índices disponíveis ao gerar um plano de execução para uma consulta. Se houver índices não utilizados, o otimizador poderá gastar mais tempo considerando esses índices, levando a planos de consulta inadequados e execuções de consulta mais lentas.

• Sobrecarga de manutenção: a manutenção dos índices requer recursos, como CPU e E/S de disco. Se você tiver um grande número de índices não utilizados, esses recursos serão desperdiçados em tarefas de manutenção de índice desnecessárias.

Sobrecarga¶

A sobrecarga diz respeito ao acúmulo de linhas inativas e não utilizadas em um banco de dados, resultando em consumo de espaço em disco e degradação de desempenho. Afeta principalmente bancos de dados com altas cargas de trabalho de transações. O sistema MVCC do Postgres cria várias versões de uma linha para sustentar transações simultâneas. Quando uma linha é atualizada ou excluída, uma nova versão é criada, enquanto a versão antiga é marcada como inativa. Essas linhas inativas não são imediatamente removidas da tabela para preservar a integridade transacional e garantir a consistência dos dados durante operações simultâneas.

Para recuperar o espaço em disco ocupado pelas linhas inativas, o Postgres realiza um vacuum periodicamente. Esse processo identifica e elimina as linhas inativas da tabela, liberando espaço em disco para reutilização. A sobrecarga ocorre quando transações elevadas geram um número substancial de linhas inativas entre os processos do vacuum.

Apresentamos a porcentagem de sobrecarga para mostrar a quantidade de espaço ocupado por linhas inativas em comparação com o tamanho total da tabela ou do índice. A sobrecarga exibida é uma estimativa ou aproximação. Se você precisar de mais dados sobre a sobrecarga em suas tabelas, poderá usar a extensão pgstattupple, apesar que essa operação pode exigir muitos recursos.

Baixa sobrecarga: em geral, uma sobrecarga abaixo de 50% é considerada aceitável e não costuma exigir nenhuma ação. Ainda é recomendado monitorá-la para verificar se continua crescendo e conferir as configurações e os ajustes do vacuum.

Alta sobrecarga: um valor acima de 50% sugere um alto nível de sobrecarga que pode começar a prejudicar gravemente o desempenho e a utilização do espaço em disco. Convém considerar uma ação, como realizar uma operação de vacuum manual ou alterar as configurações do vacuum, se você observar consultas lentas ou problemas de desempenho.

Não exibimos a porcentagem da sobrecarga se ela é inferior a 10% ou para tabelas com menos de 1GB.

Consultas discrepantes¶

Trata-se das consultas com o maior tempo de execução proporcional. Isso pode incluir consultas muito lentas, mas relativamente esporádicas, e consultas um pouco lentas, mas extremamente comuns. As consultas com o maior tempo de execução proporcional são o melhor ponto de partida para ajustar a consulta a banco de dados no nível do aplicativo ou na indexação.

Consultas de longa duração¶

As consultas de longa duração no PostgreSQL podem ter várias implicações negativas para seu banco de dados e aplicativo. Veja a seguir algumas razões pelas quais as consultas de longa duração costumam ser consideradas indesejáveis:

• Impacto no desempenho: as consultas de longa duração ocupam recursos do banco de dados, incluindo CPU, memória e E/S de disco, por um período estendido.

• Aumento da contenção: as consultas de longa duração podem levar ao aumento da contenção de recursos compartilhados, como bloqueios e acesso simultâneo a objetos de banco de dados.

• Taxa de transferência reduzida: quando uma consulta leva muito tempo para ser concluída, isso pode limitar o número de consultas que podem ser executadas em um determinado período.

• Experiência do usuário ruim: se o seu aplicativo depende da execução de consultas no prazo, as consultas de longa duração podem prejudicar a experiência do usuário. Os usuários podem sofrer atrasos ou falta de resposta, levando à frustração e insatisfação com o seu aplicativo.

• Esgotamento de recursos: as consultas de longa duração podem consumir memória excessiva, levando ao aumento do uso de memória e a possíveis erros de falta de memória. Elas também podem gerar grandes arquivos temporários no disco, causando problemas de espaço em disco.

Vacuum¶

O painel de insights também inclui as estatísticas do vacuum. Você pode verificar os nomes das tabelas, o último vacuum e o último autovacuum. Você também pode ver insights sobre quantas linhas inativas existem, quando o vacuum realizou a limpeza de linhas inativas pela última vez e muito mais.

As estatísticas do vacuum incluem:

• Nome da tabela

• Último vacuum: a última vez que uma operação de vacuum manual foi executada

• Último autovacuum: a última vez que o autovacuum foi executado

• Contagem de linhas: a contagem total de linhas da tabela

• Contagem de linhas inativas: o número atual de linhas não limpas/inativas na tabela

• Fator de escala: o fator de escala atual definido nas configurações do autovacuum

• Limite: o número total de linhas, usando o fator de escala, que exigiria uma operação de vacuum

• Vacuum necessário: se você precisa executar o vacuum manualmente na tabela

Tamanhos de tabela¶

Os detalhes sobre os tamanhos das tabelas do Postgres estão disponíveis nos insights da instância, em Table Sizes. As informações das tabelas apresentadas são:

• nomes das tabelas

• contagens aproximadas de linhas

• tamanho total da tabela

• tamanho dos índices na tabela

• número de bytes nas tabelas TOAST

• tamanho bruto da tabela de linhas

Conexões¶

O insight de conexões exibe todas as conexões atualmente ativas e ociosas na instância do banco de dados. As conexões ativas estão em uma sessão atualmente conectada ao banco de dados e que está executando uma consulta ou aguardando a execução de uma.

Conexões ociosas são comuns e não são um problema inerente, mas podem se tornar um problema dependendo da sua carga de trabalho e configuração. As conexões ociosas consomem memória, portanto, um grande número delas pode levar ao uso excessivo de memória. Normalmente, as conexões ociosas indicam que o banco de dados se beneficiaria do pool de conexões.

Cada sessão em execução tem um pid, que é o ID do processo: um identificador exclusivo atribuído a cada conexão de back-end ativa.

Para cancelar uma conexão, uma consulta ou um processo, mas deixar a sessão aberta, use esta instrução:

SELECT pg_cancel_backend(<pid>);

Uma ação mais rigorosa, que fechará a conexão e reverterá as transações, é:

SELECT pg_terminate_backend(<pid>);