Checklist de performance do PostgreSQL 8.0

Segue a tradução do texto do Josh Berkus (desenvolvedor do PostgreSQL). Este texto é um bom ponto de partida para quem está aprendendo sobre tuning no PostgreSQL 8.0. Espero em breve atualizar o artigo para as versões 8.1 e 8.2.

[ Hits: 24.817 ]

Por: Fábio Telles Rodriguez em 15/01/2007 | Blog: http://savepoint.blog.br


Hardware



Tradução livre do texto "PostgreSQL 8.0 Performance Checklist", publicado por Josh Berkus em 12/01/2005 em:
Copyright (c) 2005 by Josh Berkus and Joe Conway. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).

Aqui está um conjunto de regras para configurar seu servidor PostgreSQL 8.0. Muito do que está abaixo é baseado em evidências ou testes de escalabilidade práticos; há muito sobre performance de bancos de dados que nós e a OSDL, ainda estamos trabalhando. Contudo, isto deve ser um inicio. Todas as informações abaixo são úteis a partir de 12 de janeiro de 2005 e serão atualizadas depois. Discussões sobre configurações abaixo superam as que eu realizei no General Bits.

Cinco Princípios de Hardware para Configurar o seu Servidor PostgreSQL

1. Discos > RAM > CPU

Se você vai gastar dinheiro em um servidor PostgreSQL, gaste em arranjos de discos de alta performance e tenha processadores medianos e uma memória adequada. Se você tiver um pouco mais de dinheiro, adquira mais RAM. PostgreSQL, como outros SGDBs que suportam ACID, utilizam E/S muito intensamente e é raro uma aplicação utilizar mais a CPU do que a placa SCSI (com algumas exceções, claro). Isto se aplica tanto a pequenos como grandes servidores; obtenha uma CPU com custo baixo se isso permitir você comprar uma placa RAID de alta performance ou vários discos.

2. Mais unidades de discos == Melhor

Tendo múltiplos discos, o PostgreSQL e a maioria dos sistemas operacionais irão paralelizar as requisições de leitura e gravação no banco de dados. Isto faz uma enorme diferença em sistemas transacionais, e uma significativa melhoria em aplicações onde o banco de dados inteiro não cabe na RAM. Com os tamanhos mínimos de discos (72GB) você será tentado a utilizar apenas um disco ou um único par espelhado em RAID 1; contudo, você verá que utilizando 4, 6 ou até 14 discos irá render um impulso na performance. Ah, e SCSI é ainda significativamente melhor em fluxo de dados em BD que um IDE ou mesmo um Serial ATA.

3. Separe o Log de Transações do Banco de Dados

Assumindo que você já investiu dinheiro num arranjo com tamanho decente num conjunto de discos, existe um monte de opções mais inteligentes do que jogar tudo num único RAID. De inicio coloque o log de transações (pg_xlog) no seu próprio recurso de discos (um arranjo ou um disco), o que causa uma diferença de cerca de 12% na performance de bancos de dados com grande volume de gravações. Isto é especialmente vital em pequenos sistemas com discos SCSI ou IDE lentos: mesmo em um servidor com dois discos, você pode colocar o log de transações sobre o disco do sistema operacional e tirar algum benefício.

4. RAID 1+0/0+1 > RAID 5

RAID 5 com 3 discos tem sido um desafortunado padrão entre vendedores de servidores econômicos. Isto possibilita a mais lenta configuração de discos possível para o PostgreSQL; você pode esperar pelo menos 50% a menos de velocidade nas consultas em relação ao obtido com discos SCSI normais. Por outro lado, foque em RAID 1 ou 1+0 para um conjunto de 2, 4 ou 6 discos. Acima de 6 discos, o RAID 5 começa a ter uma performance aceitável novamente, e a comparação tende a ser bem melhor com base na sua controladora individual. No entanto, o mais importante, usar uma placa RAID barata pode ser um risco; é sempre melhor usar RAID por software do que um incorporado numa placa Adaptec que vem com seu servidor.

5. Aplicações devem rodar bem junto

Outro grande erro que eu vejo em muitas organizações e colocar o PostgreSQL em um servidor com várias outras aplicações competindo pelos mesmos recursos. O pior caso é colocar o PostgreSQL junto com outros SGDBs na mesma máquina; ambos bancos de dados irão lutar pela banda de acesso aos discos e o cache de disco do SO, e ambos vão ter uma performance pobre. Servidores de arquivo e programas de log de segurança também são ruins. O PostgreSQL pode compartilhar a mesma máquina com aplicações que utilizam principalmente CPU e RAM intensamente, como o Apache, garantindo que exista RAM suficiente.

    Próxima página

Páginas do artigo
   1. Hardware
   2. postgresql.conf
Outros artigos deste autor

Unificando bases de dados com Schemas

Leitura recomendada

Autenticação no PostgreSQL - com exemplos

Encoding do Postgres (latin1) e encoding do SO (Debian/Ubuntu)

PostgreSQL + phpPgAdmin no CentOS 5

HowTo: Como criar Cluster Linux - Ativo/Passivo para Postgres com DRBD, Pacemaker e Corosync

PostgreSQL - Instalação inicial no Debian Wheezy 64 bits

  
Comentários
[1] Comentário enviado por gelemeurer em 16/01/2007 - 10:52h

Legal, gostei!

[]s


GM

[2] Comentário enviado por removido em 17/01/2007 - 19:59h

Muito interessante, valeu mesmo!

[3] Comentário enviado por a.fernando em 17/01/2008 - 14:40h

muito bom

obrigado pela tradução

[4] Comentário enviado por fdmarp em 21/03/2009 - 12:58h

simples, mas gostei

[5] Comentário enviado por lucas.fricke em 13/01/2010 - 16:14h

Básico, mas explicativo, legal...

[6] Comentário enviado por lucas.fricke em 13/01/2010 - 16:16h

valew pela tradução


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts