Quanta memória o PostgreSQL usa no Windows?

2

Tenho o PostgreSQL 9.0 de 64 bits no Windows Server 2003 de 64 bits. O sistema tem 8 x CPUs 3G e 8 GB de memória.

Como posso / devo definir as seguintes configurações?:

  • shared_buffers
  • work_mem
  • maintenance_work_mem

O banco de dados é usado para anayltics. Apenas dois ou três usuários estão conectados a qualquer momento executando consultas. Os conjuntos de dados podem ser entre 1 milhão e 15 milhões de linhas, eu acho.

O armazenamento subjacente é um storage array EMC CX que é conectado por canal de fibra. O desempenho aqui é muito bom.

    
por NJ01 01.05.2011 / 21:32

4 respostas

1

Você encontrará respostas detalhadas para esses três em Ajustando seu servidor PostgreSQL , juntamente com sugestões sobre alguns outros parâmetros você pode querer ajustar. Você não poderá usar configurações grandes para shared_buffers no Windows, há uma queda consistente onde ele deixa de ajudar cerca de 512MB. Ative o log_temp_files e veja o que aparece para descobrir se você realmente precisa aumentar o work_mem. Com base no que você está dizendo sobre seu conjunto de dados, que não parece ter grandes dúvidas individuais, talvez você nem precise se preocupar com isso. Um aumento moderado no maintenance_work_mem pode ser útil para o trabalho de autovacuum em segundo plano, mas a menos que isso se torne um problema para você, não é crítico ajustar-se muito alto.

    
por 11.05.2011 / 05:10
3

Os valores corretos dependem do padrão de uso. No entanto, aqui estão algumas diretrizes

shared_buffers: 25% do tamanho da memória para um servidor postgresql dedicado. work_mem: é usado para operações como ordenação. Uma única conexão pode usar esse valor várias vezes, portanto, tenha cuidado com essa se tiver várias consultas em execução simultaneamente. Este requer muitos testes para ver se melhora o desempenho, mas não faz com que o sistema use muita memória. Então, se você aumentar isso, certifique-se de que seu sistema não comece a usar muita memória. Pessoalmente eu geralmente começo com algo como 4MB.

maintenance_work_mem: este é para certas operações de manutenção, como vácuo e indexação, o que o torna bastante alto é, em geral, salvo. 64M ou 128M normalmente é suficiente.

defina também o tamanho efetivo do cache. Esta é uma dica para o planejador e deve ser definida para a quantidade de memória usada como cache de disco pelo sistema operacional + o tamanho do buffer compartilhado.

Se você quiser fazer um ajuste extenso, recomendo ler um bom livro sobre isso: PostgreSQL 9.0 High Performance .

    
por 02.05.2011 / 07:36
3

Para conjuntos de dados muito grandes, você pode descobrir que uma SAN não é a ideal. As SANs se destacam em muitos e muitos pequenos ios muito rapidamente. Eles geralmente estão bem na taxa de transferência sequencial, a menos que você tenha uma interconexão muito rápida com eles e, mesmo assim, eles geralmente não são otimizados para taxa de transferência sequencial. Eu testei o desempenho de gravação de leitura sequencial e aleatório em minhas máquinas com Areca e LSI RAID Cards com cache com bateria, interface SAS nativa com RAID de software Linux e com uma SAN no back-end. O mais rápido para o acesso aleatório foi perto de um empate com a SAN e as placas RAID, mas para a taxa de transferência sequencial, o RAID de software do Linux os colocou no chão. Onde o HW RAID pode obter 350M / seo SAN estava na faixa de 100M / s (ele está conectado no gig e), o SAS nativo com SW RAID recebe cerca de 1G / s de leituras e cerca de 80% nas leituras. Tudo sequencial, claro. Não assuma que sua SAN é super rápida para o que você está fazendo, pode ser, pode não ser. Teste com bonnie ++ ou dd ou algo para ter uma ideia de quão rápido ele realmente é. Se você está ficando ~ 100MB / s sequencial, então será dolorosamente lento ao lado de uma máquina mais barata com 4 ou 8 unidades SATA de 7200RPM executando RAID-10 para análise.

Quando você diz 8x CPUs 3GHz, você quer dizer 8x sockets, cada um com 4 ou 8 núcleos? Ou 8 núcleos? Ou 4 núcleos com hyperthreading? para o seu tipo de trabalho, qualquer coisa além do total de 4 núcleos provavelmente será um desperdício. Qualquer coisa além dos 8 núcleos é definitivamente um desperdício. Com o OLAP / Analytics, você quer CPUs menos rápidas, se conseguir usá-las.

Ligado às suas configurações. shared_mem não precisa ser muito grande. No Windows, a implementação da memória compartilhada é sub ótima para valores grandes, e torná-la maior raramente ajuda a melhorar o desempenho. Dito isso, testaria vários valores para ver, mas algumas centenas de megas provavelmente seriam o mais rápido possível. trabalho de manutenção mem pode estar na faixa gig, mas o grande ganho é aumentar mais de 100M ou mais. work_mem é a metralhadora postgresql. Se você estiver indo para cima, e eu recomendo ir pelo menos 16 ou 32M em sua máquina, certifique-se de que você está limitando o parâmetro max_connections do postgresql para algumas dezenas de conexões no máximo. Se, de alguma forma, alguém iniciar várias consultas de uma só vez, você poderá ficar sem RAM rapidamente. Não é bom. OTOH, alguns testes provavelmente mostrarão que qualquer coisa acima de cem realmente não ajuda muito.

O perigo de colocar o work_mem em um nível muito alto é que ele acabará empurrando os dados armazenados em cache pelo sistema operacional para fora do cache, precisando apenas ser recarregados novamente. O custo de acessar os discos para obter esses dados geralmente é mais alto do que o ganho de realmente aumentar o volume.

Uma boa regra é manter work_mem * max_connections * 2 < 1/4 de memória. Então, em uma máquina com 64G de ram e 100 conexões, você gostaria de work_mem * 200 < 16G ou cerca de 80 Megs max. Isso garante que qualquer comportamento patológico em que todas as conexões sejam de vários tipos não matem a máquina muito rapidamente.

Se você achar que work_mem do 1G funciona muito melhor do que 100M etc, então você pode comprometer deixando o work_mem regular mais baixo para segurança e ter o único thread que executa grandes consultas definir sua própria work_mem na conexão.

Concordo com o cartaz anterior de que o windows é sub-ótimo para pgsql, com ênfase que é muito pior para o OLAP, onde a possibilidade de alocar mais shared_memory pode ser uma vantagem para o pg / linux.

    
por 02.05.2011 / 22:48
1

OK. Você diz que "o desempenho do IO é muito bom". Isso não significa muito, mas suponho que esse tipo de hardware tenha um bom fluxo seqüencial de E / S ...

Suas consultas parecem do estilo "churn through muitos dados para retornar alguns resultados agregados" com baixo paralelismo.

Conselhos sobre isso dependerão do tamanho dos dados.

Se o seu banco de dados (ou pelo menos a parte acessada com frequência) for pequeno o suficiente para ser bem armazenado em cache na RAM, seu desempenho de I / O não será muito importante (exceto para gravações); no entanto, se o seu banco de dados for enorme e você quiser revê-lo rapidamente, o desempenho sequencial de I / O será importante.

De qualquer forma, primeiro as mais fáceis:

work_mem

Quando você faz uma consulta com alguns tipos e hashes (para junções e agregações) ou tuplestores materializados, cada um pode usar até work_mem. As classificações podem derramar em disco, mas não em hashes. Observe que, se sua consulta tiver N sort, ela usará N times work_mem. Com muitos usuários isso é importante. No seu caso, poucos usuários, você pode configurá-lo bastante alto, talvez 128MB. Desta forma, os hashes ainda serão permitidos, mesmo para conjuntos de dados maiores, que podem ser muito mais rápidos do que a classificação. Você pode alterá-lo antes de executar uma consulta, se precisar também.

maintenance_work_mem

A mesma coisa, para criação de índice e afins. Criar um índice btree é uma grande espécie, portanto, configurar maintenance_work_mem para algo grande como 1-2GB exigirá menos trocas de classificação (ou seja, arquivos temporários) se você criar um índice em uma tabela grande. Lembre-se de não iniciar 10 criações de índice simultaneamente ao restaurar esse backup ...

Mais detalhes - > veja a documentação

Quanto a shared_buffers, no Windows eu não sei. Você deve perguntar a lista de discussão.

Lembre-se também que o pg pode usar apenas um núcleo por consulta, então desabilite o hyperthreading. Várias consultas, examinando a mesma tabela em paralelo, serão sincronizadas apenas para ler os dados uma vez.

A propósito, existe alguma razão para você não estar executando o Linux nessa caixa? O PG é mais "nativo" no Linux.

    
por 02.05.2011 / 18:58