ajustando o postgresql para grandes quantidades de memória ram

Eu tenho dois servidores idênticos (em termos de hardware), ambos são instalações padrão do Windows Server 2008 R2, com o mínimo de software instalado (basicamente meu código e coisas necessárias, como jvm etc).

Em um servidor, estou executando o sql server 2005, no segundo servidor postgresql 9.1. A diferença no desempenho desses dois servidores é impressionante, é tão ruim no postgresql que lamento meu discurso inicial "vamos usar o postgresql em vez de pagar pela licença do servidor sql" para meu chefe. Estamos falando de diferenças de 30 segundos vs 15 minutos para o mesmo comando, e não é apenas este comando, é qualquer consulta ou comando que eu lance nele. Ambos têm praticamente os mesmos dados (os registros foram inseridos em ordem diferente) e os dois bancos de dados têm exatamente a mesma estrutura / índices, etc.

Mas espero que seja apenas uma questão de ajuste de desempenho. O problema é que o sql server está usando praticamente todos os 32 GB de RAM no servidor, enquanto o postgresl não está usando nada, definitivamente menos do que um gig, embora eu ainda não tenha descoberto isso com detalhes.

Como faço para o postgresql usar mais de 20 GB de RAM? Esses servidores foram criados especificamente para esse material de banco de dados, portanto, qualquer ram não usado pelo banco de dados e pelos processos de suporte é desperdiçado na minha opinião.

Existem muitas constantes ajustáveis, inicializadas via postgres.conf. Os mais importantes são:

• max_connections: o número de sessões simultâneas
• work_mem : a quantidade máxima de memória a ser usada para resultados intermediários, como tabelas de hash e para classificação
• shared_buffers a quantidade de memória dedicada ao espaço do buffer 'fixado'.
• effective_cache_size a quantidade de memória que se supõe ser usada pelos buffers LRU do sistema operacional.
• random_page_cost : uma estimativa para o custo relativo das buscas em disco.

max_connectionsnão deve ser definido como mais alto do que o necessário, as conexões custam recursos mesmo quando ociosas; na maioria dos casos, uma conexão passaria mais tempo esperando dentro do que esperando fora. (pelo preço da simultaneidade) Uma boa fórmula geral é "número de eixos + número de processadores + X"

work_memé complicado: pode ser aplicado a todas as subconsultas; portanto, uma consulta com 5 HASHJOINSpode custar 5 * work_mem. E para os piores cenários, você também deve pensar em várias sessões consumindo esse valor (novamente uma razão para se manter max_connectionsbaixo).

shared_buffersé (IMHO) sobrestimado. Normalmente, é aconselhável configurá-lo para cerca de 1/4 ... 1/2 de toda a memória "livre" disponível, mas costumo mantê-la baixa e configurada effective_cache_sizepara toda a memória "livre" disponível.

random_page_costé o custo de uma pesquisa + leitura no disco. É relativo a sequential_disk_cost, que é 1. O padrão (4) para random_page_costé definido muito alto para máquinas modernas e armazenamento em rede, normalmente pode ser reduzido para 2 e 1.x. Para discos SSD, você deve configurá-lo para 1.0, pois a procura é quase gratuita nos SSDs.

Considere usar o pgtune para ajudá-lo a ajustar a configuração do PostgreSQL. Partida PgFoundry:

O pgtune pega o postgresql.conf padrão do wimpy e expande o servidor de banco de dados para ser tão poderoso quanto o hardware no qual está sendo implantado

A configuração padrão do PostgreSQL é muito conservadora e essa ferramenta serve para ajudar nessa situação exata. A documentação é uma leitura leve e o uso da ferramenta é bastante direto.

Lembre-se de que não há necessidade de usar as sugestões exatas do pgtune. Brincando com suas configurações e observando as alterações resultantes no arquivo conf, você entenderá melhor a configuração do PostgreSQL e como ajustá-la manualmente.

Se todas as consultas ou comandos estiverem sendo executados lentamente, suspeito que:

• você se conecta ao banco de dados para todas as consultas executadas;
• você configurou algum tipo de método de autenticação, que não funciona e interrompe suas consultas até que esse método de autenticação específico atinja o tempo limite.

Você poderia nos dizer quanto tempo leva para executar uma consulta como select version()? Se deve ser instantâneo (0,16 ms na minha estação de trabalho).

Se TODAS as consultas forem muito mais lentas, algo está terrivelmente errado com o servidor ou algo assim. Na minha experiência, cada banco de dados tem algumas coisas em que é melhor que o outro, mas o pgsql em termos de desempenho está facilmente no mesmo domínio que o servidor mssql.

Então, em qual SO você está executando o pgsql? Qual hardware? Quais configurações você já mudou? Qual é o tamanho do seu conjunto de dados? O que é um exemplo de uma consulta ruim e a saída da explicação de análise (execute sua consulta assim:

explicar analisar selecionar ... restante da consulta aqui ...;

Poste a saída em http://explain.depesz.com/ e poste o link aqui.