Home - www.devmedia.com.br


Otimização do PostgreSQL - Introdução
 

Muitas pessoas acham o PostgreSQL um SGBD lento logo depois dos primeiros testes após a instalação. O que acontece na realidade, é que até a versão 7.3, o PostgreSQL tem uma configuração padrão muito conservadora, o que não permite o aproveitamento do potencial da máquina na qual o servidor é instalado. Na versão 7.4 algumas configurações são determinadas dinamicamente durante a inicialização do banco o que deve mitigar o problema. Mas de qualquer maneira é essencial para o administrador entender quais parâmetros determinam a performance do PostgreSQL e saber como alterá-los a seu favor, e é esse entendimento que o presente artigo pretende trazer ao leitor. Em primeiro lugar vamos esclarecer que existem duas maneiras de otimizar a performance de um SGBD, uma é melhorando o aproveitamento do hardware disponível, outra é melhorando a organização dos dados e das consultas feitas no banco. Pretendo me deter só ao primeiro tipo nesse artigo, deixando o segundo tipo para um outro artigo (que envolverá o uso de índices, vacuum, cluster e explain).
A maior parte desse artigo é baseada em um tutorial do Bruce Momjian que pode ser encontrado em: http://www.ca.postgresql.org/docs/momjian/hw_performance/

Dois tipos de memória
Parte da otimização do uso de hardware é baseada em manter as informações mais frequentemente requisitadas próximas ao CPU, isso é feito ajustando a configuração de uso de memória. Podemos separar as configurações de memória do PostgreSQL em dois tipos, a compartilhada e a individual. A compartilhada tem um tamanho fixo, ela é alocada uma vez, na inicialização do PostgreSQL, e compartilhada por todos os clientes conectados ao banco. A memória individual tem um tamanho variável e é alocada separadamente para cada conexão feita ao banco.

Memória compartilhada
O PostgreSQL nunca faz leituras ou escritas diretamente no disco, ao invés disso, ele sempre utiliza primeiro a memória cache compartilhada, caso as informações necessárias não estejam lá, uma requisição ao sistema dearquivos é feita para buscá-las no disco. Possibilitando que o SGBD aproveite melhor o seu cache e faça um número menor de requisições ao disco rígido (tarefa mais lenta) estaremos aumentando a performance geral do banco. O tamanho desse cache compartilhado é definido pelo parâmetro shared_buffers no arquivo postgresql.conf. A sua configuração padrão é de 64 blocos de 8 Kb, ou seja 512 Kb de memória, em máquinas mais modernas esse valor pode ser muito maior. Você pode estar se perguntando: qual o limite para esse tamanho? Bom isso depende de quanta memória a máquina tem disponível para o PostgreSQL, não esqueça que um número muito grande pode gerar uso de memória virtual, que será armazenada no disco e prejudicará a performance do sistema. Para monitorar o uso de memória virtual você pode usar ferramentas como top ou vmstat.
Observe que para configurar o uso da memória compartilhada, muitas vezes é necessário ajustar alguns parâmetros do kernel do sistema operacional utilizado. Antes de alterar qualquer configuração desse tipo, recomendo a leitura da seção do manual do PostgreSQL sobre como ajustar diferentes tipos de kernel em: http://developer.postgresql.org/docs/postgres/kernel-resources.html

Memória individual
Um dos espaços de memória individual alocado pelo PostgreSQL é usado para o ordenamento de registros. Ela é utilizada toda vez que o SGBD precisa reordenar um determinado conjunto de registros, em operações de CREATE INDEX, ORDER BY ou merge joins. Para reordenar conjuntos de registros muito grandes o PostgreSQL cria arquivos temporários parciais e junta todos eles após concluir o reordenamento. Desse modo, quanto maior a memória de ordenamento, menor será o número de arquivos temporários criados e mais rápida será a operação. A quantidade de memória de ordenamento é definida em Kb pelo parâmetro sort_mem no postgresql.conf. A configuração padrão é bastante conservadora, portanto é adequado aumentar esse número também. Convém lembrar que cada conexão com o banco poderá utilizar uma área do tamanho definido, o que pode aumentar muito o uso de memória dependendo do número médio de conexões. Para limitar o tamanho alocado para a memória de ordenamento, leve em consideração a memória disponível (contando com a memória já alocada para o cache compartilhado), o número médio de conexões e o uso da memória virtual.

Exemplo de configuração
Nesse exemplo eu considero um servidor dedicado (rodando somente o PgSQL) com 1,5 Gb de RAM e até 10 conexões simultâneas com o banco. de memória em um servidor dedicado (rodando somente o PgSQL) usando 1,5 Gb de RAM

shared_buffers = 80000 # 80.000 blocos de 8 Kb = 625 Mb
sort_mem = 64000 # tamanho em Kb=62,5 Mb, p/ cada usuário conectado
# 10 usuários = 625 Mb.
vacuum_mem = 2000

Usando vários discos
Caso você pretenda utilizar uma máquina com mais de um disco rígido disponível, você pode aumentar a performance do sistem distribuindo algumas tarefas entre discos diferentes. Uma maneira de tirar vantagem disso é movendo os logs de transação para um disco a parte. Os logs de transação são os únicos registros que não podem ter o seu salvamento em disco adiado sem comprometer a segurança do sistema. Colocando-os em um disco separado um grande número de requisições ao sistema de arquivos vai deixar de ser feito no disco com os dados, o que aumenta a performance do banco. Para fazer isso você deve desligar o PostgreSQL, mover a pasta pg_xlog, que está dentro do diretório de dados da sua instalação, para o disco secundário, e criar um link simbólico no local onde ele estava.
Outra possibilidade de aproveitamento de vários discos é colocar os índices em um disco diferente das tabelas do banco. Isso também pode ser feito desligando o PostgreSQL, movendo os índices para um novo local e cirando links simbólicos no local original. Além disso é possível separar algumas tabelas mais acessadas em um disco separado, para isso usa-se o mesmo método utilizado nos índices.

Usando vários processadores
Já vi alguns usuários perguntarem se o PostgreSQL é capaz de aproveitar o potencial de máquinas com mais de um processador. Normalmente sim, pois cada conexão feita com o banco de dados é geerenciada por um processo diferente, que o sistema operacional pode alocar para o processador mais adequado. Caso você utilize poucas conexões concomitantes com a base de dados, o ganho não é tão grande, pois uma conexão não pode usar mais de um processador.

Sistema de arquivos
Muitas pessoas perguntam nas listas de dicussão qual o melhor sistema de arquivos para se utilizar o PostgreSQL. A resposta é simples, não existe "o melhor sistema de arquivos". A escolha natural para quem utiliza algum sistema BSD é o tradicional UFS, é um sistema de arquivos robusto, rápido, e tem a vantagem de possuir um tamnho padrão de 8 Kb para os blocos de disco, o mesmo tamanho dos blocos de dados do PostgreSQL. Já para quem utiliza Linux a escolha é mais difícil, pois existem muitas opções disponíveis. Embora alguns recomendem o uso de ext2 pelo ganho de velocidade, eu me sinto mais seguro usando o ext3 no modo writeback. E
embora isso possa parecer uma tradução exata do artigo original do Bruce Momjiam, é uma afirmação baseada em minhas experiências. Outro sistema de arquivos no qual eu já usei muito o PgSQL é o ReiserFS, e ele combina performance e confiabilidade muito bem. Quanto a outros sistemas como XFS e JFS não posso falar, pois nunca os utilizei.

Checkpoints
O último parâmetro de configuração do qual vou falar é o wal_files, que determina o número de arquivos usados pelo PostgreSQL para armazenar os logs de transação. Esses arquivos são aqueles presentes em pg_xlog, na pasta de dados, dos quais já falei anteriormente. Cada arquivo ocupa 16 Mb em disco, e cada vez que o PostgreSQL ocupa todo o espaço disponível ele inicia um processo de reciclagem para aproveitar arquivos já exitenstes, sem nunca criar mais arquivos do que estiver determinado na configuração wal_files. Para saber se o número utilizado pelo sua configuração é satisfatório você pode observar os logs do sistema. Cada vez que um arquivo é reaproveitado um log é criado da seguinte forma:

2003-09-18 20:30:00 LOG: recycled transaction log file 0000000000000000

Caso no seu log a data e hora não apareçam você pode usar a configuração log_timestamp = true (no postgresql.conf) para medir o intervalo entre a reciclagem dos arquivos. Caso você tenha muitas requisições de gravação de dados no PostgreSQL e esse intervalo fique inferior a 5 minutos ou caso você veja a seguinte
mensagem nos logs do sistema:

LOG: XLogWrite: new log file created - consider increasing WAL_FILES

considere a possibilidade de aumentar o número de wal_files. E não se assuste caso apareçam vários logs com a mesma hora, normalmente um checkpoint recicla vários arquivos de uma vez só.

Copyleft (c) por Diogo de Oliveira Biazus (diogo.biazus@pop.com.br)
Esse texto é licenciado sob a licença GNU FDL .
GNU FDL: GPL-pt_BR.txt (http://www.postgresql.org.br/GPL-pt_BR.txt)

 

  Instalando e configurando o PostgreSQL no Slackware    
  Trabalhando com documentos XML no PostgreSQL    
  Otimização do PostgreSQL    
  Características do PostgreSQL    
     

 

Todos os direitos reservados: DevMedia Group
SQL Magazine - 2004