Revisão do postgresql.conf

8,525 views

Published on

Tabela comparando todos parâmetros do arquivo de configuração postgresql.conf do PostgreSQL nas versões 7.4, 8.0, 8.1 e 8.2

Published in: Technology
1 Comment
4 Likes
Statistics
Notes
  • interessante e útil
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
8,525
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
344
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide

Revisão do postgresql.conf

  1. 1. Comparações e Observações sobre versões do portgresql.conf Este documento é uma comparação das versões do arquivo postgresql.conf do PostgreSQL nas versões 8.2, 8.1, 8.0 e 7.4, que serão as versões suportadas pela equipe do PostgreSQL a partir do lançamento da versão 8.2. A documentação a respeito da versão 8.2 foi realizada a partir da versão 8.2 beta3 e pode sofrer atualizações até a versão definitiva da documentação. Erros de tradução, digitação, omissões e sugestões podem ser enviadas para Fábio Telles em fabio.telles@gmail.com para que este documento possa ser melhorado. Notas de Copyright Este documento foi compilado por Fábio Telles e pode ser modificado e redistribuído nos termos das licenças abaixo, que são as fontes as informações utilizadas para a realização do presente documento. As observações deste documento são traduções do artigo Annotated POSTGRESQL.CONF Guide for PostgreSQL de Josh Berkus e Joe Conway disponível em http://www.powerpostgresql.com/Downloads/annotated_conf_80.html Licenciado pela Licença OPL A coluna documentação é baseada na tradução da documentação do PostgreSQL em portug uês disponível em http://pgdocptbr.sourceforge.net/pg80/ realizada pelo Projeto de Tradução para o Português do Brasil a partir da documentação oficial, Copyright © 1996-2006 The PostgreSQL Glo bal Development Group Locais dos Arquivos Configurado Parâmetro 8.2 8.1 8.0 7.4 Escopo Padrão em Documentação OBS data_directory (string) X X X Diretório ConfigDir Inicialização Especifica o diretório a ser utilizado para Estas configurações permitem a fácil armazenamento dos dados. administração de uma instalação do PostgreSQL onde várias configurações e config_file (string) X X X Arquivo ConfigDir/ Inicialização Especifica o arquivo principal de configuração do arquivos de monitoramento são postgresql.conf servidor. separados do banco de dados em si, hba_file (string) X X X Arquivo ConfigDir/ Inicialização Especifica o arquivo de configuração para usualmente para propósitos de arquivos pg_hba.conf autenticação baseada no hospedeiro. de administração com especificações particulares, ou para automatizar testes com diferentes configurações. Se você usar isto, será necessário apenas especificar a localização do arquivo
  2. 2. Locais dos Arquivos postgresql.conf em si quando iniciar o postmaster (usando a opção -D ou ConfigDir/ Especifica o arquivo de configuração para a ident_file (string) X X X Arquivo pg_ident.conf Inicialização autenticação ident. PGDATA). Esta nova abordagem é considerada melhor do que criar links simbólicos, a única opção anterior.
  3. 3. Locais dos Arquivos Isto é para programas de administração e Interfaces GUI que esperam encontrar o Especifica o nome de um arquivo de identificação PID do PostgreSQL num local específico, external_pid_file de processo adicional, que o postmaster deve usualmente em /var. Tenha em mente que (string) X X X Arquivo Inicialização criar para uso pelos programas de administração este é apenas uma cópia do PID e não do servidor. aquele checado pelo pg_ctl na inicialização do servidor, que será checado no diretório de dados.
  4. 4. Conexões e Autenticação Configurado Parâmetro 8.2 8.1 8.0 7.4 Escopo Padrão -o Documentação OBS em X X X -h Definições da Conexão listen_addresses localhost Inicialização Especifica o endereço, ou endereços, de TCP/IP Esta configuração substitui “tcp_ip” e (string) x onde o servidor atende as conexões dos “virtual_host” do 7.4. A maioria dos aplicativos cliente. O valor tem a forma de uma usuários irão querer configurar em '*' -i lista de nomes de hospedeiros, ou de endereços para escutar todos os endereços ou numéricos de IP, separados por vírgula. A deixar isto em 'localhost' para uma entrada especial * corresponde a todas as máquina segura. Ao contrário das versões interfaces de IP disponíveis. Se a lista estiver anterioras, o padrão agora suporta vazia, o servidor não atende nenhuma interface conexões TCP/IP em 127.0.0.1 de forma IP e, neste caso, somente podem ser utilizados que um servidor web local possa conectar soquetes do domínio Unix para conectar ao logo após a instalação padrão. servidor de banco de dados. O valor padrão é Por motivo de segurança, altere isto após localhost, que permite serem feitas apenas configurar o seu arquivo pg_hba.conf. conexões locais quot;retornantesquot; (loopback). tcpip_socket X on / off off Inicialização Se for verdade, então o servidor aceita conexões Substituído pelo listen_addreses a partir (boolean) TCP/IP. Senão, somente são aceitas conexões da versão 8.0. oriundas do soquete do domínio Unix local. O valor padrão é desabilitado. virtual_host X Inicialização Especifica o nome de hospedeiro ou endereço Substituído pelo listen_addreses a partir (string) de IP onde o servidor está escutando as da versão 8.0. conexões das aplicações cliente. O padrão é escutar em todos os endereços configurados (incluindo localhost). port (integer) X X X X 129 a 5432 Inicialização -p A porta TCP onde o servidor está atendendo; A principal razão para utilizar uma porta 32768 # 5432 por padrão. Deve ser observado que é alternativa é a necessidade de rodar mais utilizada a mesma porta em todos os endereços de um servidor PostgreSQL numa de IP onde o servidor atende. máquina, como durante um upgrade. Uma alternativa a isto é a opção em tempo de compilação –with-port que configura uma porta alternativa em todas as bibliotecas, retirando a necessidade de lembrar da opção -p em todos os clientes utilitários. max_connection X X X X 2a 100 Inicialização - N Determina o número máximo de conexões Mantenha o mais baixo possível para a
  5. 5. Conexões e Autenticação Configurado Parâmetro 8.2 8.1 8.0 7.4 Escopo Padrão -o Documentação OBS em s (integer) 262143 # simultâneas ao servidor de banco de dados. O sua aplicação, uma vez que cada conexão valor típico é 100, mas pode ser menor se a ativa requer recursos de sistema configuração do núcleo do sistema operacional significativos. Aplicações Web servindo não não tiver capacidade para suportar este centenas de usuários devem utilizar um valor (conforme determinado durante o initdb). pool de conexões para reduzir o número Somente pode ser definido na inicialização do de conexões requeridas no banco de servidor. O aumento deste parâmetro pode fazer dados. Aumentando isto, irá requerer com que o PostgreSQL requisite mais memória ajustes no limite de memória do seu SO. compartilhada System V que o permitido pela configuração padrão do sistema operacional. Para obter informações sobre como ajustar estes parâmetros deve ser consultada a Seção 16.5.1 , se for necessário. superuser_reser X X X X 0a 2 Inicialização Determina o número de quot;encaixes de conexãoquot; Isto protege o acesso como super usuário ved_connections max_con (connection slots), reservados para os em caso do banco de dados $$$. Não (integer) nections superusuários do PostgreSQL se conectarem. configure isto em 0 a não ser que você -1 Podem estar ativas até max_connections tiver muita certeza de que o banco de conexões simultâneas. Sempre que o número de dados não pode ser quebrado. Eu sempre conexões ativas simultâneas for igual ou maior a configuro em 1, uma vez que apenas eu max_connections menos conecto ao banco de dados como super superuser_reserved_connections, somente serão usuário no caso de ocorrer algum aceitas novas conexões feitas por superusuários. problema. A configuração padrão é 2 O valor padrão é 2. O valor deve ser menor que para o caso de algum utilitário o valor de max_connections. administrativo ficar continuamente conectado como o autovacuum. unix_socket_dire X X X X '' Inicialização Especifica o diretório do soquete do domínio ctory (string) Unix onde o servidor está atendendo as conexões dos aplicativos cliente. Normalmente o valor padrão é /tmp, mas pode ser mudado em tempo de construção. unix_socket_gro X X X X '' Inicialização Define o grupo dono do soquete do domínio up (string) Unix (O usuário dono do soquete é sempre o usuário que inicializa o servidor). Combinado com o parâmetro unix_socket_permissions pode
  6. 6. Conexões e Autenticação Configurado Parâmetro 8.2 8.1 8.0 7.4 Escopo Padrão -o Documentação OBS em ser utilizado como um mecanismo de controle de acesso adicional para as conexões do domínio Unix. Por padrão é uma cadeia de caracteres vazia, que utiliza o grupo padrão do usuário corrente. unix_socket_per X X X X 0777 Inicialização Define as permissões de acesso do soquete do missions domínio Unix. Os soquetes do domínio Unix (integer) utilizam o conjunto usual de permissões do sistema de arquivos do Unix. Para o valor deste parâmetro, é esperada uma especificação de modo numérica, na forma aceita pelas chamadas de sistema chmod e umask (Para utilizar o formato octal, como é de costume, o número deve começar por 0 (zero)). As permissões padrão são 0777, significando que qualquer um pode se conectar. Alternativas razoáveis são 0770 (somente o usuário e o grupo, consulte também unix_socket_group), e 0700 (somente o usuário); deve ser observado que, na verdade, para soquetes do domínio Unix somente a permissão de escrita tem importância, não fazendo sentido conceder ou revogar permissões de leitura e de execução. Este mecanismo de controle de acesso é independente do descrito no Capítulo 19 . bonjour_name X X '' Inicialização Especifica o nome de difusão (broadcast) (string) Bonjour. O nome do computador é utilizado se o parâmetro usar o valor de uma cadeia de caracteres vazia (''). Este parâmetro é ignorado se o servidor não for compilado com suporte ao Bonjour. tcp_keepalives_i X X 0 Inicialização Em sistemas com suporte a opção de soquete dle (integer) TCP_KEEPIDLE, especifica o número de
  7. 7. Conexões e Autenticação Configurado Parâmetro 8.2 8.1 8.0 7.4 Escopo Padrão -o Documentação OBS em segundos entre o envio de keepalives em uma conexão ociosa. O valor 0 utiliza o padrão do sistema. Se TCP_KEEPIDLE não é suportado, este parâmetro precisa ser 0. Este parâmetro é ignorado para conexões feitas através de soquete Unix. Em sistemas que suporta ma opção de soquete TCP_KEEPINTVL, especifica o quão longa é, em segundos, a espera por uma resposta para o tcp_keepalives_i keepalive antes de uma retransmissão. O valor 0 nterval (integer) X X 0 Inicialização usa o padrão do sistema. Se o TCP_KEEPINTVL não é suportado, este parâmetro precisa ser 0. Este parâmetro é ignorado para conexões feitas através de soquete Unix. Em sistemas que suportam a opção de soquete TCP_KEEPCNT, especifica quantos keepalives podem ser perdidos antes da conexão ser tcp_keepalives_c considerada morta. Um valor de 0 usa o padrão ount (integer) X X Inicialização do sistema. Se o TCP_KEEPCNT não é suportado, este parâmetro precisa ser 0. Este parâmetro é ignorado para conexões feitas através de soquete Unix. Especifica o nome de difusão (broadcast) Rendezvous. Por padrão é utilizado o nome do rendezvous_nam computador, especificado através de uma cadeia e (string) X X '' Inicialização de caracteres vazia (''). É ignorado quando o servidor não é compilado com suporte a Rendezvous.
  8. 8. Conexões e Autenticação Configurado Parâmetro 8.2 8.1 8.0 7.4 Escopo Padrão -o Documentação OBS em Segurança e autenticação Tempo máximo, em segundos, para completar a autenticação do cliente. Se a tentativa de Se você está rodando um servidor web tornar-se cliente não completar o protocolo de ocupado, você irá querer diminuir o autenticação nesta quantidade de tempo, o timeout da conexão. Certamente você vai authentication_ti 1 a 600 servidor derruba a conexão. Isto impede que querer combinar com o timeout do seu meout (integer) X X X X seg. 60 Reload middleware, ou então você poderá ficar clientes travados fiquem ocupando a conexão indefinidamente. Somente pode ser definido na desnecessariamente indisponível ou vai inicialização do servidor, ou no arquivo esperar muito durante os períodos postgresql.conf. ocupados. O SSL é uma alternativa criptografada ao acesso plano a porta TCP/IP, e é um requerimento para clientes preocupados com a segurança da informação, Habilita conexões SSL. Por favor leia a Seção particularmente em uma rede wireless. O ssl (boolean) X X X X on / off off Inicialização 16.7 antes de utilizar este parâmetros. PostgreSQL envia consultas e dados em texto plano, mesmo quando a senha está encriptada. SSL pode ser complicado de configurar e dar manutenção, e nem todos softwares clientes podem suportar o acesso SSL. Quando é especificada uma senha em CREATE Deve estar habilitado, no arquivo de USER ou ALTER USER , sem que seja escrito configuração e por conexão. Não há password_encry ENCRYPTED ou UNENCRYPTED, este ption (boolean) X X X X on / off On Inicialização nenhuma razão para ter um banco de parâmetro determina se a senha deve ser dados com senhas de usuários não criptografada. encriptados. Configura a localização do arquivo com a chave krb_server_keyfil do servidor Kerberos. Veja Secção 19.2.3 para Apenas utilizado para usuários com e (string) X X X X '' Inicialização autenticação Kerberos. detalhes. krb_srvname Configura o nome do serviço Kerberos. Veja a (string) X X '' Inicialização Seção 20.2.3 para detalhes.
  9. 9. Conexões e Autenticação Configurado Parâmetro 8.2 8.1 8.0 7.4 Escopo Padrão -o Documentação OBS em krb_server_host X X '' Inicialização Configura o nome da parte hospedeira do name (string) serviço principal. Este, combinado com krb_srvname, é utilizado para gerar o serviço completo principal que é krb_srvname/ krb_server_hostname@ REALM. Se não for configurado, o padrão é o nome do host. Veja Seção 20.2.3 para detalhes. krb_caseins_user X X on / off off Inicialização Configura de os nomes dos usuários Kerberos s (boolean) devem ser tratados como insensíveis a maiúsculas e minúsculas (case-insensitive). O padrão é off (case sensitive). db_user_namesp X X off Inicialização Permite nomes de usuário por banco de dados. Esta funcionalidade suporta instalações ace (boolean) O valor padrão é falso. Se o valor for verdade, (como em provedores de acesso) onde é os usuários devem ser criados como necessário usuários por banco de dados. nome_do_usuário@nome_bd. Quando o É uma forma deselegante na melhor das nome_do_usuário é passado por um cliente se hipóteses e será removida quando uma conectando, são anexados @ e o nome do banco solução melhor para este problema for de dados ao nome do usuário, então o servidor criada. Assim, não use esta opção se você procura por este nome de usuário específico do puder viver sem ela. banco de dados. Deve ser observado que, no ambiente SQL, para criar nomes de usuário contendo @ é necessário colocar o nome de usuário entre aspas. Quando o valor deste parâmetro é verdade, ainda podem ser criados usuários globais comuns. Deve apenas ser anexado o caractere @ à especificação do nome de usuário no cliente. O caractere @ será retirado antes do nome de usuário ser procurado pelo servidor. Nota: Esta funcionalidade foi criada como uma medida temporária até que seja encontrada uma solução definitiva, quando então será
  10. 10. Conexões e Autenticação Configurado Parâmetro 8.2 8.1 8.0 7.4 Escopo Padrão -o Documentação OBS em removida.
  11. 11. Consumo de recursos Configurado Parâmetro 8.2 8.1 8.0 7.4 Escopo Padrão -o Documentação OBS em X X X X -B Memóriai shared_buffers 16 a 1000 Inicialização Define o número de buffers de memória Configurar o shared_buffers requer uma (integer) 2621143 (4000 na x compartilhada, utilizados pelo servidor de banco discussão mais longa que este espaço na de dados. O valor típico é 1000, mas pode ser dispõe. Por favor veja outro artigo sobre versão menor se a configuração do núcleo do sistema este tópico. 8.2) operacional não não tiver capacidade para Para regras práticas: em um servidor suportar este valor (conforme determinado PostgreSQL dedicado, este valor deve durante o initdb). Cada buffer possui 8192 estar entre 1000 e 50000 (8MB e bytes, a menos que seja escolhido um valor 400MB). Fatores que aumentam o diferente para BLCKSZ ao construir o servidor. montante recomendado são mais O valor definido deve ser pelo menos igual a 16, conexões, porções mais largas do banco assim como pelo menos duas vezes o valor de de dados ativas, consultas longas e max_connections ; entretanto, normalmente é complexas e tabelas largas. A RAM necessário definir um valor bem maior que o avaliável limita o máximo shared_buffers; mínimo para obter um bom desempenho. São você deve usar no máximo 1/3 da sua recomendados valores de alguns poucos RAM avaliável. milhares para instalações de produção. Somente pode ser definido na inicialização do servidor. O aumento deste parâmetro pode fazer com que o PostgreSQL requisite mais memória compartilhada System V que o permitido pela configuração padrão do sistema operacional. Para obter informações sobre como ajustar estes parâmetros deve ser consultada a Seção 16.5.1 , se for necessário. sort_mem X 1024 Inicialização Equivalente a opção work_men. (integer) vacuum_mem X 8192 Inicialização Equivalente a opção maintenance_work_mem. (integer) temp_buffers X X 1000 Inicialização Ajusta o número máximo de buffers temporários (integer) usados por cada seção do banco de dados. Estes buffers são locais a sessão e usados apenas no acesso a tabelas temporárias. A configuração pode ser trocada em sessões individuais, mas
  12. 12. apenas até o primeiro uso de uma tabela temporária na sessão; subseqüentes tentativas de alterar o valor não terão efeito nesta sessão. Uma sessão irá alocar buffers temporários conforme a necessidade até o limite dado por temp_buffers. O custo desta configuração em um valor grande em sessões que atualmente não necessitam de muito temporary_buffers é apenas o descritor do buffer, ou cerca de 64 bytes, por incremento no temp_buffers. Contudo, se um buffer é atualmente utilizado um adicional de 8192 bytes (ou geralmente, BLCKSZ bytes). Ajusta o número máximo de transações que podem estar “preparadas” simultaneamente (veja PREPARE TRANSACTION ). Configurando este parâmetro para zero desabilita a funcionalidade de transações preparadas. Se você não está usando transações preparadas, este parâmetro poderá ser configurado para max_prepared_tr zero. Se você utiliza-las, você provavelmente irá ansactions querer que max_prepared_transactions sejam (integer) X X 5 Inicialização tão grandes quanto max_connections, para evitar falhas desnecessárias na etapa de preparação. Aumentando este parâmetro fará o PostgreSQL requisitar mais memória compartilhada ao System V que a configuração padrão do seu sistema operacional permite. Veja Seção 16.4.1 para informações sobre como ajustar estes parâmetros. Especifica a quantidade de memória utilizada Antigamente conhecida como sort_mem, pelas operações internas de classificação e esta configuração teve seu nome trocado tabelas de dispersão (hash tables), antes de para refletir o seu papel estendido em alternar para arquivos temporários em disco. O governar não apenas ordenações. valor é especificado em kilobytes, e o valor Work_mem é uma troca direta. Ajuste ele padrão é 1024 kilobytes (1 MB). Deve ser para cima para: grandes bancos de observado que, em uma consulta complexa, dados, consultas complexas, muita podem ser executadas várias classificações ou memória RAM disponíveis. Ajuste para
  13. 13. Mapa do espaço livre max_fsm_pages X X X X 1000 a 20000 Inicialização Define o número máximo de páginas de disco Um ajuste propício do FSM pode eliminar (integer) int_max para as quais o espaço livre será acompanhado ou pelo menos adiar a necessidade de no mapa de espaço livre compartilhado. São rodar um VACUUM FULL e REINDEX. A consumidos seis bytes de memória melhor forma de configurar isto é a compartilhada para cada encaixe de página. O seguinte: valor definido deve ser maior que 16 * 1)Entenda que a freqüência de VACUUM max_fsm_relations. O valor padrão é 20000. (regular) do seu banco de dados é Somente pode ser definido na inicialização do baseado na atividade de escrita; servidor. 2)Rode o banco de dados sobre carga de produção normal, e rode o VACUUM VERBOSE ANALYZE ao invés do VACUUM, gravando a saída em um arquivo. 3)Calcule o número máximo de páginas reparadas entre os VACUUMs baseado na saída e utilize-o. Alternativamente, se você estiver utilizando o Autocacuum, você pode se basear como uma porcentagem do total de páginas do seu banco de dados, para casar com a porcentagem do autovacuum. Pouca memória é requerida por página (cerca de 6 bytes por página), então é melhor ser generoso do que avarento. Favor notar que bancos de dados com grandes “picos” de atividade (surtos de 1 milhão de atualizações tanto para minutos ou horas) este número pode ser impossível de ajustar perfeitamente. Linhas inseridas não são significativas para FSM. Finalmente, se o seu servidor de banco de dados tem pouca RAM, aumentar FSM para os valores necessários pode ser contra-produtivo. max_fsm_relatio X X X X 1000 Inicialização Define o número máximo de relações (tabelas e Poucos usuários vão precisar ajustar este ns (integer) índices) para as quais o espaço livre será número, mas é melhor checar. Você deve acompanhado no mapa de espaço livre ter ao menos tantas FSM_relations compartilhado. São consumidos, quantas tabelas em todos os seus bancos aproximadamente, 50 bytes de memória de dados, incluindo o banco de dados de
  14. 14. compartilhada por cada encaixe. O valor padrão modelo e o esquema de sistema. O é 1000. Somente pode ser definido na PostgreSQL desenvolve uma performance inicialização do servidor. ímpar uma vez que não se tenha FSM_relations o suficiente. X X X X Utilização de Recursos do Cerne max_files_per_pr 10 a 1000 Inicialização Define o número máximo permitido de arquivos Para constar, mais utilizado no BSD. Não ocess (integer) int_max abertos simultaneamente por cada subprocesso se preocupe com ele a não ser que você servidor. O valor padrão é 1000. Se o núcleo receba a mensagem “too many files”. tiver um limite de segurança por processo, não é necessário se preocupar com esta definição. Entretanto, em algumas plataformas (notadamente a maioria dos sistemas BSD), o núcleo permite que processos individuais abram muito mais arquivos que o sistema pode suportar, quando um grande número de processos tenta abrir esta quantidade de arquivos ao mesmo tempo. Se for vista a mensagem de erro quot;Muitos arquivos abertosquot; deve-se tentar reduzir esta definição. preload_libraries X Diretório Inicialização Especifica uma ou mais bibliotecas Isto é útil apenas para bancos de dados (string) compartilhadas a serem pré-carregadas durante específicos com propósitos a inicialização do servidor. Pode ser chamada, especializados. Por exemplo, o opcionalmente, uma função de inicialização sem mapeamento do banco de dados pode ter parâmetros para cada biblioteca. Para um pequeno de performance com a pré- especificá-la deve ser adicionado dois-pontos e o carga as bibliotecas GIS. Para a maioria nome da função de inicialização após o nome da dos sistemas, é melhor deixar isto vazio. biblioteca. Por exemplo '$libdir/minha_bib:minha_bib_inic' faz com que minha_bib seja pré-carregada e minha_bib_inic seja executada. Para carregar mais de uma biblioteca, os nomes devem ser separados por vírgula. Se minha_bib ou minha_bib_inic não for encontrada, a inicialização do servidor não será bem-sucedida. As bibliotecas de linguagem procedural do PostgreSQL são pré-carregadas desta maneira, usualmente utilizando a sintaxe '$libdir/plXXX:plXXX_init', onde XXX é pgsql, perl, tcl ou python. Fazendo a pré-carga da biblioteca
  15. 15. compartilhada (e a inicializando, se for aplicável), ganha-se o tempo de inicialização da biblioteca quando a biblioteca é utilizada pela primeira vez. Entretanto, pode aumentar ligeiramente o tempo para inicializar cada novo processo servidor, mesmo que o processo nunca utilize a biblioteca. Portanto, este parâmetro só é recomendado para bibliotecas utilizadas pela maioria das sessões. Se uma biblioteca específica não é encontrada, o servidor vai falhar na inicialização. Todas as bibliotecas suportadas pelo PostgreSQL possuem um “bloco mágico” que é checado para garantir a compatibilidade. Por esta razão, bibliotecas não-PostgreSQL não podem ser carregadas desta forma.
  16. 16. Esta configuração é extremamente valiosa quando estiver realizando o Retardo do VACUUM baseado no custo vacuum em grandes tabelas que de outra A quantidade de tempo, em milissegundos, que forma iriam concorrer pela E/S por o processo adormece quando o custo limite é longos períodos e bloquear numerosas excedido. O valor padrão é 0, que desabilita a consultas. Ativar o o vacuum_delay, funcionalidade de retardo do VACUUM baseado essencialmente quebra o vacuum em uma no custo. Valores positivos habilitam o retardo grande tabela em segmentos definidos vacuum_cost_de Tempo de do VACUUM baseado no custo. Deve ser como quantidades de trabalhos lay (integer) X X X 0 execução observado que em muitos sistemas a resolução específicos, entre o adormecimento do efetiva de adormecimento é de 10 vacuum e o tempo definido nesta milissegundos; definir vacuum_cost_delay com configuração. Isto tem o efeito final de um valor que não é múltiplo de 10, pode ter o aumentar o tempo requerido pelo mesmo resultado que definir com o próximo vacuum, possivelmente em alguns múltiplo de 10 maior que o valor especificado. múltiplos, mas reduzindo o impacto global no sistema do vacuum, em até 85%. Valores razoáveis para o atraso estão entre 50ms e 200ms. O custo estimado para executar o VACUUM em um buffer encontrado no buffer cache Esta configuração deverá provavelmente vacuum_cost_pa Tempo de compartilhado. Representa o custo para ge_hit (integer) X X X 1 execução ser deixada como está em favor de bloquear o buffer pool, examinar a tabela hash manipular o vacuum_cost_limit. compartilhada, e varrer o conteúdo da página. O custo estimado para executar o VACUUM em um buffer que precisa ser lido no disco. vacuum_cost_pa Representa o esforço para bloquear o buffer Esta configuração deverá provavelmente Tempo de ge_miss X X X 10 execução pool, examinar a tabela hash compartilhada, ler ser deixada como está em favor de (integer) o bloco desejado no disco e varrer o seu manipular o vacuum_cost_limit. conteúdo. O custo estimado cobrado quando o VACUUM vacuum_cost_pa modifica um bloco que foi limpo anteriormente. Esta configuração deverá provavelmente Tempo de Representa a E/S adicional necessária para ge_dirty X X X 20 execução ser deixada como está em favor de (integer) descarregar no disco novamente um bloco que manipular o vacuum_cost_limit. foi limpo anteriormente. O custo acumulado que faz com que o processo executando o VACUUM adormeça. Nota: Existem determinadas operações que Diminua isto para quebrar o vacuum em prendem bloqueios críticos e que devem, mais “segmentos”. Uma combinação portanto, terminar o mais rápido possível. O bastante agressiva seria um
  17. 17. Especifica o retardo entre rodadas de atividade para escritor de segundo plano. A cada rodada o Escrita em segundo Plano escritor escreve uma quantidade de buffers sujos (controlado pelos parâmetros mostrados a seguir). Os buffers selecionados são sempre os O escritor de segundo plano é uma nova usados menos recentemente entre os buffers funcionalidade desenvolvida para aliviar sujos atuais. Em seguida adormece por a carga dos checkpoints. bgwriter_delay bgwriter_delay milissegundos e repete a Nós ainda estamos realizando testes com (integer) X X X 200 Inicialização operação. Deve ser observado que em muitos as configurações do bgwriter no OSDL; sistemas a resolução efetiva do adormecimento não há nenhuma recomendação até o é de 10 milissegundos; definir bgwriter_delay momento. com um valor que não é múltiplo de 10, pode ter o mesmo resultado que definir com o próximo múltiplo de 10 maior que o valor especificado. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf. A cada rodada não será escrito mais que esta percentagem de buffers sujos no momento (as Nós ainda estamos realizando testes com bgwriter_percent frações são arredondadas para o próximo as configurações do bgwriter no OSDL; (integer) X 1 Inicialização número inteiro de buffers acima). Somente pode não há nenhuma recomendação até o ser definido na inicialização do servidor, ou no momento. arquivo postgresql.conf. A cada rodada não será escrito mais que esta Nós ainda estamos realizando testes com bgwriter_maxpa quantidade de buffers sujos. Somente pode ser as configurações do bgwriter no OSDL; ges (integer) X 100 Inicialização definido na inicialização do servidor, ou no não há nenhuma recomendação até o arquivo postgresql.conf. momento. Para reduzir a probabilidade do processo do servidor precisar realizar suas próprias escritas, o escritor de segundo plano tenta gravar buffers que serão provavelmente reciclados logo. Em bgwriter_lru_per cada rodada, ele examina o cent (floating X X 1,0 Inicialização bgwriter_lru_percent dos buffers que estão mais point) próximos de serem reciclados e escreve naquele que estiver sujo. O valor padrão é 1.0 (este é um porcentual com o número total de shared_buffers). Em cada rodada, não mais que estes buffers bgwriter_lru_ma serão gravados como resultado da busca aos xpages (integer) X X 5 Inicialização buffers próximos de serem reciclados.
  18. 18. Log de escrita prévia (WAL) Configurado Parâmetro 8.2 8.1 8.0 7.4 Escopo Padrão -o Documentação OBS em fsync (boolean) X X X X on / off on Inicialização -F Se o valor deste parâmetro for on, o servidor Desligue o WAL (fsync=off) apenas em PostgreSQL utilizará a chamada de sistema banco de dados somente para leitura ou fsync() em vários lugares para ter certeza que onde o banco de dados pode ser as atualizações estão fisicamente escritas no restaurado a partir de um software disco. Isto garante que o agrupamento de externo. Enquanto RAID mais No-breacks bancos de dados vai ser recuperado em um podem fazer muito para proteger seus estado consistente após um problema de dados, desligando fsync, significa que máquina ou do sistema operacional você irá restaurar a partir do backup em caso de falha de hardware ou energia. Entretanto, a utilização de fsync() produz uma degradação de desempenho: quando a Por outro lado, o WAL impões uma transação é efetivada, o PostgreSQL tem de penalidade significativa a escrita em aguardar o sistema operacional descarregar o banco de dados, especialmente em log de escrita prévia no disco. Quando fsync sistemas com apenas um disco. está desabilitado, o sistema operacional pode Essencialmente você está dobrando a desempenhar da sua melhor maneira a quantidade de leitura/gravação requerida quot;buferizaçãoquot;, ordenação e retardo na escrita. por uma atualização e ainda requerendo Isto pode produzir uma melhora significativa no que você desabilite as funcionalidades de desempenho. Porém, no caso de uma queda do cache de disco do seu hardware e SO. sistema, podem ser perdidos, em parte ou por Então, se seus dados são dispensáveis, inteiro, os resultados das poucas últimas desligar o Fsync é uma boa consideração. transações efetivadas. No pior caso, os dados Se o WAL estiver desligado, o resto podem ficar corrompidos de uma forma destas opções nesta seção são irrecuperável (Para esta situação a queda do irrelevantes. servidor de banco de dados não é um fator de risco, somente há risco dos dados ficarem corrompidos no caso de queda do sistema operacional). Devido aos riscos envolvidos não existe uma definição universalmente aceita para fsync. Alguns administradores sempre desabilitam fsync, enquanto outros só desabilitam para cargas de dado pesadas, onde claramente existe
  19. 19. um ponto de recomeço se algo de errado acontecer, enquanto outros administradores sempre deixam fsync habilitado. O valor padrão para fsync é habilitado, para obter o máximo de confiabilidade. Havendo confiança no sistema operacional, na máquina, e nos utilitários que acompanham (ou na bateria de reserva), pode- se levar em consideração desabilitar fsync. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf. Se você desligar este parâmetro, desligue também o full_page_writes. Método utilizado para obrigar a colocar as atualizações do WAL no disco. Os valores possíveis são fsync (chamada à função fsync() a cada efetivação), fdatasync (chamada à função fdatasync() a cada efetivação), open_sync (escreve os arquivos WAL com a opção O_SYNC da função open()), e open_datasync (escreve A chamada de sistema utilizada para arquivos WAL com a opção O_DSYNC do sincronizar o WAL no disco. O padrão fsync, open()). Nem todas estas opções estão deve ser ajustado para cada SO baseado fdatasyn disponíveis em todas as plataformas. Somente na documentação do SO, nas nenhum Varia c, pode ser definido na inicialização do servidor, teste profundo de comparação foi wal_sync_method com a (string) X X X X open_syn platafor Inicialização ou no arquivo postgresql.conf. postado. É possível que trocar de método c, pode melhorar a velocidade de escrita da ma open_datasync (escreve os arquivos WAL files open_dat sua plataforma, mas não brinque com isto async com open() opção O_DSYNC) a não ser que você tenha tempo e fdatasync (chama fdatasync() em cada recursos para rodar testes comparativos commit) e de falhas. fsync_writethrough (chama fsync() em cada commit, forçando escrever através de qualquer cache de escrita em disco) fsync (chama fsync() em cada commit) open_sync (escreve os arquivos WAL com open() opção O_SYNC) full_page_writes X X on / off on Inicialização Quando este parâmetro está ligado, o servidor (boolean) PostgreSQL grava todo o conteúdo de cada página de disco para o WAL durante a primeira modificação daquela página após o checkpoint. Isto é preciso porque a gravação da página que
  20. 20. está em progresso durante uma queda de sistema está apenas parcialmente completada, deixando uma página em disco que contém um misto de dados novos e velhos. A mudança em nível de linha normalmente armazenada no WAL não será o suficiente para restaurar completamente a página durante uma recuperação pós queda. Armazenando a imagem completa da página garante que a página será corretamente restaurada, mas ao preço de aumentar o volume de dados que precisam ser gravados no WAL. (Porque a repassagem do WAL sempre começa a partir do checkpoint, é suficiente fazer custo durante a primeira alteração em cada página após o checkpoint. Assim, uma forma de reduzir o custo da gravação da página cheia é aumentar o parâmetro de intervalo do checkpoint. Desligando esta opção resulta numa velocidade normal de operação, mas poder levar a corrupção do banco de dados após uma falha no Sistema Operacional ou energia. O risco é semelhante a desligar o fsync, apesar de menor. Deve ser seguro desligar este parâmetro se você tiver um hardware (como uma controladora de discos com bateria) ou software de sistema de arquivos que reduza o risco de gravações parciais de páginas em um nível aceitável (ex. ReiserFS 4). Desligar este parâmetro não afeta o uso do WAL archiving para point-in-time-recovery (PITR) (veja a Seção 23.3). Número de buffers de página de disco alocados Aumentar este parâmetro tem resultado na memória compartilhada para os dados do num efeito mínimo, mesmo em um WAL. O valor padrão é 8. Esta definição sistema OLTP muito ocupado. Se você 4a somente precisa ser grande o suficiente para wal_buffers (integer) X X X X max_int 8 Inicialização sabe que terá transações muito longas, conter a quantidade de dados do WAL gerados você poderá aumentar isto só para estar por uma transação típica. Somente pode ser seguro (para 16 a 64), mas foque o ajuste definido na inicialização do servidor. mais em checkpoint_segments.
  21. 21. Retardo entre a escrita do registro de efetivação no buffer do WAL e a descarga do buffer no disco, em microssegundos. Um retardo maior Estas duas opções são configuradas que zero permite que seja feita apenas uma juntas para um grande volume de chamada de sistema fsync() para várias pequenas transações. Quando ajustadas, transações efetivadas, se a carga do sistema for elas permitem um grupo de diferentes alta o suficiente para que outras transações transações serem enviadas ao disco ao fiquem prontas para efetivar dentro do intervalo mesmo tempo, com um possível ganho commit_delay 0a Tempo de (integer) X X X X 100000 0 execução especificado. Entretanto, este retardo é significativo de performance. Contudo, simplesmente desperdício se nenhuma outra este é uma troca ao esperar alguns transação ficar pronta para efetivar. Portanto, o milissegundos extras em cada transação. retardo somente é realizado se pelo menos Se você quiser testar se isto aumenta a outras commit_siblings transações estiverem performance para você, um bom ponto de ativas no instante que o processo servidor partida é um commit_delay de 500 (½ escrever seu registro de efetivação. O valor milissegundo). padrão é zero (nenhum retardo). Se estiver usando o commit_delay, você vai querer alterar esta opção dependendo do comprimento médio das transações Número mínimo de transações simultâneas no seu sistema. Se as transações forem abertas requerido para realizar o retardo muito curtas (comandos de commit_siblings Tempo de commit_delay. Um valor maior torna mais atualização/inserção simples de uma (integer) X X X X 1 a 1000 5 execução provável que pelo menos uma outra transação linha) então você irá utilizar valores fique pronta para efetivar durante o período do baixos como um commit simultâneo é retardo. O valor padrão é 5. mais provável. Se as transações são longas, você vai querer aumentar isso para evitar o uso desnecessário do commit_delay. checkpoint_segments X X X X 1a 3 Inicialização Distância máxima entre pontos de controle Esta é a opção mais efetiva para lidar (integer) int_max automático do WAL, em segmentos de arquivo com grandes atualizações, carga de de log (cada segmento possui normalmente 16 dados e atividade pesada de OLTP. Para MB). O valor padrão é 3. Somente pode ser qualquer sistema com pesada atividade definido na inicialização do servidor, ou no de escrita, você deverá aumentar isto arquivo postgresql.conf. para ao menos 8; em sistemas com grandes cargas (como a carga de alguns GB de dados), algo em torno de 128 (e nós usamos 256 para testar o DBT2). Contudo, isto requer um montante significativo de espaço em disco para o xlog ((2 x segmentos + 1 ) x 16 MB, para

×