Conceitos essenciais para ajuste do Aurora PostgreSQL

Antes de ajustar seu banco de dados Aurora PostgreSQL, aprenda o que são eventos de espera e por que eles ocorrem. Reveja também a arquitetura básica de memória e disco do Aurora PostgreSQL. Para obter um diagrama de arquitetura útil, consulte o wikibook PostgreSQL.

Eventos de espera do Aurora PostgreSQL

Um evento de espera indica um recurso pelo qual uma sessão está aguardando. Por exemplo, o evento de espera Client:ClientRead ocorre quando o Aurora PostgreSQL está aguardando para receber dados do cliente. Os recursos comuns que uma sessão aguarda incluem:

• Acesso com thread único a um buffer, por exemplo, quando uma sessão está tentando modificar um buffer

• Uma linha que está bloqueada por outra sessão

• Uma leitura de arquivo de dados

• Uma gravação em arquivo de log

Por exemplo, para satisfazer uma consulta, a sessão pode realizar uma varredura de tabela completa. Se esses dados ainda não estiverem na memória, a sessão aguardará a conclusão da E/S do disco. Quando os buffers são lidos na memória, talvez a sessão precise aguardar, pois outras sessões estão acessando os mesmos buffers. O banco de dados registra as esperas utilizando um evento de espera predefinido. Esses eventos estão agrupados em categorias.

Por si só, um evento de espera não mostra um problema de performance. Por exemplo, se os dados solicitados não estão na memória, é necessário ler dados do disco. Se uma sessão bloquear uma linha para uma atualização, outra sessão aguardará que essa linha seja desbloqueada para poder atualizá-la. Uma confirmação exige a conclusão da gravação em um arquivo de log. Esperas são componentes integrais do funcionamento normal de um banco de dados.

Em geral, muitos eventos de espera indicam um problema de performance. Nesses casos, é possível utilizar os dados dos eventos de espera para determinar onde as sessões estão perdendo tempo. Por exemplo, se um relatório que é normalmente executado em minutos passou a demorar várias horas, é possível identificar os eventos de espera que mais contribuem para o tempo de espera total. Se você puder determinar as causas dos principais eventos de espera, às vezes pode aplicar alterações que melhoram a performance. Por exemplo, se a sua sessão está aguardando uma linha que foi bloqueada por outra sessão, é possível encerrar a sessão responsável pelo bloqueio.

Memória do Aurora PostgreSQL

A memória do Aurora PostgreSQL está dividida em compartilhada e local.

Tópicos

• Memória compartilhada no Aurora PostgreSQL
• Memória local no Aurora PostgreSQL

Memória compartilhada no Aurora PostgreSQL

O Aurora PostgreSQL aloca memória compartilhada quando a instância é iniciada. A memória compartilhada está dividida em várias subáreas. A seguir, você encontrará uma descrição das mais importantes.

Tópicos

• Buffers compartilhados
• Buffers de log de gravação antecipada (WAL)

Buffers compartilhados

O grupo de buffer compartilhado é uma área de memória do Aurora PostgreSQL que contém todas as páginas que estão ou estavam sendo utilizadas por conexões de aplicações. Uma página é a versão de memória de um bloco de disco. O grupo de buffer compartilhado armazena em cache os blocos de dados lidos do disco. O grupo reduz a necessidade de reler dados do disco, fazendo com que o banco de dados opere de maneira mais eficiente.

Cada tabela e índice são armazenados como uma matriz de páginas com tamanho fixo. Cada bloco contém várias tuplas, que correspondem a linhas. Uma tupla pode ser armazenada em qualquer página.

O grupo de buffer compartilhado possui memória finita. Se uma nova solicitação exigir uma página que não esteja na memória e não houver mais memória, o Aurora PostgreSQL removerá uma página utilizada com menos frequência para acomodar essa solicitação. A política de despejo é implementada por um algoritmo de varredura de relógio.

O parâmetro shared_buffers determina a quantidade de memória que o servidor dedica ao armazenamento em cache de dados.

Buffers de log de gravação antecipada (WAL)

Um buffer de log de gravação antecipada (WAL) mantém dados de transação que o Aurora PostgreSQL grava posteriormente no armazenamento persistente. Utilizando o mecanismo WAL, o Aurora PostgreSQL pode fazer o seguinte:

• Recupere dados após uma falha

• Reduzir a E/S de disco, evitando gravações frequentes em disco

Quando um cliente modifica dados, o Aurora PostgreSQL grava as alterações no buffer de WAL. Quando o cliente emite um COMMIT, o processo gravador WAL grava dados de transação no arquivo de WAL.

O parâmetro wal_level determina quantas informações são gravadas no WAL.

Memória local no Aurora PostgreSQL

Todo processo de backend aloca memória local para processamento de consultas.

Tópicos

• Área de memória de trabalho
• Área de memória de trabalho para manutenção
• Área de buffer temporária

Área de memória de trabalho

A área de memória de trabalhocontém dados temporários para consultas que executam classificações e hashes. Por exemplo, uma consulta com uma cláusula ORDER BY executa uma classificação. Consultas usam tabelas de hash em agregações e junções de hash.

O parâmetro work_mem é a quantidade de memória a ser utilizada por operações de classificação internas e tabelas de hash antes da gravação em arquivos de disco temporários. O valor padrão é 4 MB. Várias sessões podem ser executadas simultaneamente, e cada uma pode executar operações de manutenção em paralelo. Por esse motivo, a memória de trabalho total utilizada pode ser múltiplos da configuração work_mem.

Área de memória de trabalho para manutenção

A área de memória de trabalho para manutenção armazena dados em cache para operações de manutenção. Essas operações incluem aspiração, criação de índices e adição de chaves externas.

O parâmetro maintenance_work_mem especifica a quantidade máxima de memória a ser utilizada por operações de manutenção. O valor padrão é 64 MB. Uma sessão de banco de dados apenas pode executar uma operação de manutenção de cada vez.

Área de buffer temporária

A área de buffer temporária armazena tabelas temporárias em cache para cada sessão de banco de dados.

Cada sessão aloca buffers temporários conforme necessário até o limite especificado. Quando a sessão termina, o servidor limpa os buffers.

O parâmetro temp_buffers define o número máximo de buffers temporários utilizados por cada sessão. Antes do primeiro uso de tabelas temporárias em uma sessão, é possível alterar o valor de temp_buffers.

Processos do Aurora PostgreSQL

O Aurora PostgreSQL utiliza vários processos.

Tópicos

• Processo Postmaster
• Processos de backend
• Processos em segundo plano

Processo Postmaster

O processo de postmaster é o primeiro a ser iniciado quando você inicia o Aurora PostgreSQL. Ele tem as seguintes responsabilidades principais:

• Bifurcar e monitorar processos em segundo plano

• Receba solicitações de autenticação dos processos do cliente e autentique-as antes de permitir que o banco de dados atenda às solicitações

Processos de backend

Se o postmaster autenticar uma solicitação de cliente, o postmaster bifurcará um novo processo de backend, também chamado de processo postgres. Um processo de cliente conecta-se exatamente a um processo de backend. O processo de cliente e o processo de backend se comunicam diretamente sem a intervenção do processo postmaster.

Processos em segundo plano

O processo postmaster bifurca vários processos que realizam diferentes tarefas de backend. Alguns dos mais importantes incluem:

• Gravador WAL

  O Aurora PostgreSQL grava dados no buffer de WAL (gravação antecipada) nos arquivos de log. O princípio do registro em log de gravação antecipada determina que o banco de dados não pode gravar alterações nos arquivos de dados até que o banco de dados grave registros de log descrevendo essas alterações no disco. O mecanismo WAL reduz a E/S do disco e permite que o Aurora PostgreSQL utilize os logs para recuperar o banco de dados após uma falha.

• Gravador em segundo plano

  Esse processo grava periodicamente páginas sujas (modificadas) dos buffers de memória nos arquivos de dados. Uma página fica suja quando um processo de backend a modifica na memória.

• Daemon autovacuum

  O daemon consiste no seguinte:

  • O launcher de autovacuum

  • Os processos de operador de autovacuum

  Quando o autovacuum está ativado, ele procura tabelas que tiveram um grande número de tuplas inseridas, atualizadas ou excluídas. Esse daemon tem as seguintes responsabilidades:

  • Recuperar ou reutilizar o espaço em disco ocupado por linhas atualizadas ou excluídas

  • Atualizar estatísticas utilizadas pelo planejador

  • Proteger contra a perda de dados antigos devido à recorrência de IDs de transação

  O recurso e autovacuum automatiza a execução de comandos VACUUM e ANALYZE. VACUUM tem as seguintes variantes: padrão e completo. O vacuum padrão é executado em paralelo com outras operações de banco de dados. VACUUM FULL requer um bloqueio exclusivo na tabela em que está trabalhando. Portanto, ele não pode ser executado em paralelo com operações que acessam a mesma tabela. VACUUM cria uma quantidade substancial de tráfego de E/S, podendo piorar a performance para outras sessões ativas.