19.10. Limpeza #

19.10.1. Limpeza automática
19.10.2. Atraso do VACUUM baseado em custos
19.10.3. Comportamento padrão
19.10.4. Congelamento

Estes parâmetros controlam o comportamento da limpeza (aspiração/vacuuming). Para mais informações sobre a finalidade e as responsabilidades d limpeza, Veja Limpeza de rotina.

19.10.1. Limpeza automática #

Estas configurações controlam o comportamento da funcionalidade autovacuum. Veja Processo de limpeza automática para obter mais informações. Note-se que muitas dessas configurações podem ser mudadas por tabela individualmente; veja Parâmetros de armazenamento.

autovacuum (boolean) #

Controla se o servidor deve executar o lançador do daemon autovacuum. Está ativo por padrão; entretanto, track_counts também deverá estar ativo para que o autovacuum funcione. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor; mas, a limpeza automática pode ser desativada por tabela individualmente, alterando os parâmetros de armazenamento da tabela.

Note-se que mesmo quando este parâmetro estiver inativo, o sistema irá iniciar processos de autovacuum, se necessário, para evitar o reinício do identificador de transação. Veja Prevenção de falhas de reinício de ID de transação para obter mais informações.

autovacuum_worker_slots (integer) #

Especifica o número de encaixes de processo servidor em segundo plano (backend), a serem reservados para processos trabalhadores de autovacuum. O padrão é normalmente 16 encaixes, mas pode ser menor se as configurações do núcleo (kernel) não oferecerem suporte a isto (conforme determinado durante o initdb). Este parâmetro só pode ser definido na ativação do servidor.

Ao alterar este valor, deve-se considerar ajustar também autovacuum_max_workers.

autovacuum_max_workers (integer) #

Especifica o número máximo de processos de autovacuum (além do processo lançador de autovacuum) que pode estar em execução simultaneamente. O padrão é 3. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Note-se que uma configuração para este valor superior a autovacuum_worker_slots não terá efeito, uma vez que os processos trabalhadores de autovacuum são retirados do conjunto de encaixes estabelecido por esta configuração.

autovacuum_naptime (integer) #

Especifica o atraso mínimo entre execuções de autovacuum em qualquer banco de dados. A cada rodada, o daemon examina o banco de dados e executa os comandos VACUUM e ANALYZE, conforme necessário, para as tabelas desse banco de dados. Se o valor for especificado sem unidade, será considerado sendo segundos. O padrão é um minuto (1min). Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

autovacuum_vacuum_threshold (integer) #

Especifica o número mínimo necessário de tuplas atualizadas ou excluídas para acionar o comando VACUUM em qualquer tabela. O padrão é 50 tuplas. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor; mas esta configuração pode ser modificada por tabela individualmente, alterando os parâmetros de armazenamento da tabela.

autovacuum_vacuum_insert_threshold (integer) #

Especifica o número mínimo necessário de tuplas inseridas para acionar o comando VACUUM em qualquer tabela. O padrão é 1000 tuplas. Se for especificado -1, o autovacuum não irá disparar uma operação de VACUUM em nenhuma tabela com base no número de inserções. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor; mas esta configuração pode ser modificada por tabela individualmente, alterando os parâmetros de armazenamento da tabela.

autovacuum_analyze_threshold (integer) #

Especifica o número mínimo necessário de tuplas inseridas, atualizadas, ou excluídas, para acionar o comando ANALYZE em qualquer tabela. O padrão é 50 tuplas. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor; mas esta configuração pode ser modificada por tabela individualmente, alterando os parâmetros de armazenamento da tabela.

autovacuum_vacuum_scale_factor (floating point) #

Especifica a fração do tamanho da tabela a ser adicionada a autovacuum_vacuum_threshold ao decidir se deve acionar o comando VACUUM. O padrão é 0.2 (20% do tamanho da tabela). Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor; mas esta configuração pode ser modificada por tabela individualmente, alterando os parâmetros de armazenamento da tabela.

autovacuum_vacuum_insert_scale_factor (floating point) #

Especifica uma fração das páginas não congeladas na tabela a serem adicionadas a autovacuum_vacuum_insert_threshold ao decidir se deve disparar o VACUUM. O padrão é 0.2 (20% das páginas não congeladas na tabela). Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor; entretanto, a configuração pode ser sobreposta por tabela alterando individualmente os parâmetros de armazenamento da tabela.

autovacuum_analyze_scale_factor (floating point) #

Especifica a fração do tamanho da tabela a ser adicionada a autovacuum_analyze_threshold, ao decidir se deve acionar o comando ANALYZE. O padrão é 0.1 (10% do tamanho da tabela). Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor; mas esta configuração pode ser modificada por tabela individualmente, alterando os parâmetros de armazenamento da tabela.

autovacuum_vacuum_max_threshold (integer) #

Especifica o número máximo de tuplas atualizadas ou excluídas necessário para disparar o VACUUM em uma tabela, ou seja, um limite para o valor calculado com autovacuum_vacuum_threshold e autovacuum_vacuum_scale_factor. O padrão é 100.000.000 tuplas. Se for especificado -1, o autovacuum não irá impor um número máximo de tuplas atualizadas ou excluídas que acionariam uma operação de VACUUM. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor; mas esta configuração pode ser modificada por tabela individualmente, alterando os parâmetros de armazenamento da tabela.

autovacuum_freeze_max_age (integer) #

Especifica a idade máxima (em transações) que o campo relfrozenxid da tabela pg_class pode atingir antes que seja forçada uma operação de VACUUM para evitar o reinício do identificador de transação dentro da tabela. Note-se que o sistema irá iniciar processos de autovacuum para evitar o reinício do identificador de transação, mesmo quando o daemon autovacuum estiver inativo.

A limpeza também permite a remoção de arquivos antigos do subdiretório pg_xact, sendo por isto que o padrão é relativamente baixo, 200 milhões de transações. Este parâmetro só pode ser definido na ativação do servidor, mas a configuração pode ser reduzida por tabela individualmente, alterando os parâmetros de armazenamento das tabelas. Veja Prevenção de falhas de reinício de ID de transação para obter mais informações.

autovacuum_multixact_freeze_max_age (integer) #

Especifica a idade máxima (em multixact) que o campo relminmxid da tabela pg_class pode atingir antes que seja forçada uma operação de VACUUM para evitar o reinício do identificador multixact dentro da tabela. Note-se que o sistema irá iniciar processos de autovacuum para evitar o reinício desse identificador, mesmo quando o daemon autovacuum estiver inativo.

A limpeza multixact também permite a remoção dos arquivos antigos dos subdiretórios pg_multixact/members e pg_multixact/offsets, sendo por isto que o padrão é relativamente baixo, 400 milhões de multixacts. Este parâmetro só pode ser definido na ativação do servidor, mas a configuração pode ser reduzida por tabela individualmente, alterando os parâmetros de armazenamento das tabelas. Veja Multixacts e reinício para obter mais informações.

autovacuum_vacuum_cost_delay (floating point) #

Especifica o valor do custo de atraso usado em operações de VACUUM automáticas. Se for especificado -1, será usado o valor vacuum_cost_delay regular. Se o valor for especificado sem unidade, será considerado sendo milissegundos. O padrão é 2 milissegundos. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor; mas esta configuração pode ser modificada por tabela individualmente, alterando os parâmetros de armazenamento da tabela.

autovacuum_vacuum_cost_limit (integer) #

Especifica o valor do custo limite que será utilizado em operações de VACUUM automáticas. Se for especificado -1 (o padrão), será usado o valor vacuum_cost_limit regular. Note-se que o valor é distribuído proporcionalmente entre os processos trabalhadores de autovacuum em execução, caso haja mais de um, para que a soma dos limites de cada processo trabalhador não ultrapasse o valor dessa variável. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor; mas esta configuração pode ser modificada por tabela individualmente, alterando os parâmetros de armazenamento da tabela.

19.10.2. Atraso do VACUUM baseado em custos #

Durante a execução dos comandos VACUUM e ANALYZE, o sistema mantém um contador interno que acompanha o custo estimado das várias operações de E/S sendo executadas. Quando o custo acumulado atinge um limite (especificado por vacuum_cost_limit), o processo que executa a operação irá dormir por um curto intervalo de tempo, conforme especificado por vacuum_cost_delay. Em seguida, irá zerar o contador e continuar a execução.

O propósito desse recurso é permitir que os administradores reduzam o impacto de E/S desses comandos na atividade concorrente do banco de dados. Existem muitas situações onde não é importante que os comandos de manutenção como VACUUM e ANALYZE terminem rapidamente; no entanto, é geralmente muito importante que estes comandos não interfiram muito na capacidade do sistema de executar outras operações do banco de dados. O atraso do VACUUM em função do custo fornece uma maneira para os administradores conseguirem isto.

Este recurso está inativo por padrão para comandos VACUUM executados manualmente. Para ativá-lo, deve ser definida a variável vacuum_cost_delay para um valor diferente de zero.

vacuum_cost_delay (floating point) #

O tempo que o processo ficará em suspensão quando o limite de custo for excedido. Se este valor for especificado sem unidade, será considerado sendo milissegundos. O padrão é 0, o que desativa o recurso de atraso da limpeza baseada em custo. Valores positivos ativam a limpeza baseado em custo.

Ao usar o atraso do VACUUM em função do custo, os valores apropriados para vacuum_cost_delay são geralmente bem pequenos, talvez menos de 1 milissegundo. Embora o parâmetro vacuum_cost_delay possa ser definido como valores de milissegundos fracionários, estes atrasos podem não ser medidos com precisão em plataformas mais antigas. Nessas plataformas, aumentar o consumo de recursos do VACUUM acima do que seria obtido com 1ms exigirá a alteração de outros parâmetros de custo. Deve-se, no entanto, manter vacuum_cost_delay tão pequeno quanto a plataforma medirá consistentemente; grandes atrasos não são úteis.

vacuum_cost_page_hit (integer) #

O custo estimado para processar um buffer encontrado no cache de buffers compartilhados. Representa o custo de bloquear o buffer pool, consultar a tabela de hash compartilhada e varrer o conteúdo da página. O padrão é 1.

vacuum_cost_page_miss (integer) #

O custo estimado para limpar um buffer que precisa ser lido do disco. Representa o custo para bloquear o buffer pool, consultar a tabela de hash compartilhada, ler o bloco desejado do disco, e verificar seu conteúdo. O padrão é 2.

vacuum_cost_page_dirty (integer) #

O custo estimado cobrado quando o comando VACUUM modifica um bloco previamente limpo. Representa a E/S extra necessária para descarregar o bloco sujo para o disco novamente. O padrão é 20.

vacuum_cost_limit (integer) #

Este é o custo acumulado que fará com que o processo de limpeza entre em pausa por vacuum_cost_delay. O padrão é 200.

Nota

Existem certas operações que mantêm bloqueios críticos e, portanto, devem ser concluídas o mais rápido possível. O atraso do VACUUM em função do custo não ocorre durante estas operações. Portanto, é possível que o custo acumule muito mais do que o limite especificado. Para evitar atrasos inutilmente longos nesses casos, o atraso real é calculado como vacuum_cost_delay * accumulated_balance / vacuum_cost_limit, com um valor máximo de vacuum_cost_delay * 4.

19.10.3. Comportamento padrão #

vacuum_truncate (boolean) #

Ativa ou desativa a tentativa do vacuum de truncar quaisquer páginas vazias no final da tabela. O padrão é true. Caso seja true, o VACUUM e o autovacuum realizam o truncamento, e o espaço em disco das páginas truncadas é devolvido ao sistema operacional. Note-se que o truncamento requer um bloqueio ACCESS EXCLUSIVE na tabela. Se for especificado o parâmetro TRUNCATE no comando VACUUM, este irá se sobrepor ao valor deste parâmetro. A configuração também pode ser modificada por tabela individualmente, alterando os parâmetros de armazenamento da tabela.

19.10.4. Congelamento #

Para manter a correção mesmo após o reinício dos IDs de transação, o PostgreSQL marca linhas suficientemente antigas como congeladas. Estas linhas são visíveis por todos; as demais transações não precisam examinar o XID de inserção para determinar a visibilidade. O comando VACUUM é responsável por marcar as linhas como congeladas. As configurações a seguir controlam o comportamento de congelamento do comando VACUUM e devem ser ajustadas com base na taxa de consumo de XID do sistema e nos padrões de acesso aos dados das cargas de trabalho predominantes. Veja Prevenção de falhas de reinício de ID de transação para obter mais informações sobre o reinício do ID de transação e o ajuste desses parâmetros.

vacuum_freeze_table_age (integer) #

O comando VACUUM irá executar uma varredura agressiva se o campo relfrozenxid da tabela pg_class atingir a idade especificada por esta configuração. A varredura agressiva difere do comando VACUUM regular, porque visita todas as páginas que possam conter XIDs ou MXIDs não congelados, e não apenas aquelas que possam conter tuplas mortas. O padrão é 150 milhões de transações. Embora se possa definir este valor entre zero e dois bilhões, o comando VACUUM irá limitar silenciosamente o valor efetivo a 95% de autovacuum_freeze_max_age, para que um comando VACUUM manual periódico tenha a chance de ser executado antes que um autovacuum anti-reinício seja lançado para a tabela. Veja Prevenção de falhas de reinício de ID de transação para obter mais informações.

vacuum_freeze_min_age (integer) #

Especifica a idade limite (em transações), que o comando VACUUM deve usar para decidir se deve congelar as versões de linha durante a varredura de uma tabela. O padrão é 50 milhões de transações. Embora se possa definir este valor entre zero e um bilhão, o comando VACUUM irá limitar silenciosamente o valor efetivo à metade do valor de autovacuum_freeze_max_age, para não haver um tempo excessivamente curto entre as auto-limpezas forçadas. Veja Prevenção de falhas de reinício de ID de transação para obter mais informações.

vacuum_failsafe_age (integer) #

Especifica a idade máxima (em transações) que o campo relfrozenxid da tabela pg_class pode atingir antes que o comando VACUUM tome medidas extraordinárias para evitar a falha em todo o sistema do reinício do identificador de transação. Esta é a estratégia de último recurso do comando VACUUM. A proteção (failsafe) é normalmente acionada quando um daemon autovacuum lançado para evitar o reinício do identificador da transação já está em execução há algum tempo, embora ser possível que a proteção seja acionada durante qualquer comando VACUUM.

Quando o mecanismo de segurança é acionado, qualquer atraso baseado em custos que esteja em vigor deixará de ser aplicado, outras tarefas de manutenção não essenciais (como a limpeza de índice) serão ignoradas, e qualquer estratégia de acesso ao buffer em uso será desativado, permitindo que o comando VACUUM utilize todos os recursos da memória compartilhada.

O padrão é 1.6 bilhões de transações. Embora se possa definir este valor entre zero e 2.1 bilhões, o comando VACUUM irá ajustar silenciosamente o valor efetivo para não menos que 105% de autovacuum_freeze_max_age.

vacuum_multixact_freeze_table_age (integer) #

O comando VACUUM irá executar uma varredura agressiva se o campo relminmxid da tabela pg_class atingir a idade especificada por esta configuração. A varredura agressiva difere do comando VACUUM regular, porque visita todas as páginas que possam conter XIDs ou MXIDs não congelados, e não apenas aquelas que possam conter tuplas mortas. O padrão é 150 milhões de multixact. Embora se possa definir este valor entre zero e dois bilhões, o comando VACUUM irá limitar silenciosamente o valor efetivo a 95% de autovacuum_multixact_freeze_max_age, para que um comando VACUUM manual periódico tenha a chance de ser executado antes que seja lançado um comando VACUUM anti-reinício para a tabela. Veja Multixacts e reinício para obter mais informações.

vacuum_multixact_freeze_min_age (integer) #

Especifica a idade de corte (em multixacts) que o comando VACUUM deve utilizar para decidir se deve acionar o congelamento de páginas com um ID de multixact mais antigo. O padrão é 5 milhões de multixacts. Embora os usuários possam definir este valor em qualquer ponto entre zero e um bilhão, o comando VACUUM irá limitar silenciosamente o valor efetivo à metade do valor de autovacuum_multixact_freeze_max_age, para que não haja um intervalo excessivamente curto entre as auto-limpezas forçadas. Veja Multixacts e reinício para obter mais informações.

vacuum_multixact_failsafe_age (integer) #

Especifica a idade máxima (em multixact) que o campo relminmxid da tabela pg_class pode atingir antes que o comando VACUUM tome medidas extraordinárias para evitar a falha em todo o sistema do reinício do identificador multixact. Esta é a estratégia de último recurso do comando VACUUM. A proteção (failsafe) é normalmente acionada quando um daemon autovacuum lançado para evitar o reinício do identificador da transação já está em execução há algum tempo, embora ser possível que a proteção seja acionada durante qualquer comando VACUUM.

Quando a proteção é acionada, qualquer atraso baseado em custo existente não será mais aplicado, e outras tarefas de manutenção não essenciais (como limpeza de índice) serão ignoradas.

O padrão é 1.6 bilhões multixact. Embora se possa definir este valor entre zero e 2.1 bilhões, o comando VACUUM irá ajustar silenciosamente o valor efetivo para não menos que 105% de autovacuum_multixact_freeze_max_age.

vacuum_max_eager_freeze_failure_rate (floating point) #

Especifica o número máximo de páginas (como uma fração do total de páginas da relação) que o comando VACUUM pode varrer sem definir o estado de tudo congelado no mapa de visibilidade antes de desativar a varredura antecipada. O valor 0 desativa inteiramente. O padrão é 0.03 (3%).

Note-se que, quando a varredura antecipada (eager scanning) está ativa, apenas as falhas de congelamento contam para o limite, e não os congelamentos bem-sucedidos. O congelamento de páginas bem-sucedido é limitado internamente a 20% das páginas da relação que estão inteiramente visíveis, mas não inteiramente congeladas. Limitar o número de congelamentos de página bem-sucedidos ajuda a distribuir a sobrecarga entre várias operações de limpeza normais e reduz o impacto negativo de congelamentos antecipados desperdiçados — ou seja, de páginas modificadas novamente antes da próxima operação de limpeza agressiva.

Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor; mas a definição pode ser sobreposta para tabelas alterando individualmente o parâmetro de armazenamento correspondente da tabela. Para obter mais informações sobre como ajustar o comportamento de congelamento da limpeza, veja Prevenção de falhas de reinício de ID de transação.