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.
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.
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.
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.
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.
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.