Opção shared_buffers no PostgreSQL

4

Eu tenho um servidor com 4GB de RAM e PostgreSQL 9.0.3 no Centos 5. Estou usando pgbench e pgbench-tools para medir o desempenho usando duas pgbench-tools consultas: select e tpc-b .

Com as configurações padrão de postgresql.conf e usando uma consulta de seleção, obtenho os seguintes resultados:

Scale: 1, 10, 100, 1000.
Transactions per second: 10000, 8800, 7500, 100.

(o número de registros da tabela é escala * 100000)

Eu aumentei a opção shared_buffer para 256MB (anteriormente era de 32 MB) e obtive os seguintes resultados:

Scale: 1, 10, 100, 1000.
Transactions per second: 10000, 8000, 3200, 30

Por que o desempenho é tão baixo comparado ao primeiro teste quando a escala é de 100 ou mais no segundo benchmark? A única coisa que fiz foi aumentar a memória.

    
por doctore 29.04.2011 / 16:41

1 resposta

1

A única coisa que torna o pgbench mais lento quando você aumenta shared_buffers é uma opção de depuração chamada verificação de asserção. Se você fizer isso no psql:

show debug_assertions;

E está ativado, sua versão tem esse problema e os resultados que você está vendo são esperados. Você precisa de uma nova instalação que não esteja ativada para que a depuração de asserções faça isso desaparecer.

Caso contrário, se você não fez tudo isso mais de uma vez, eu não teria tanta certeza de que a causa aqui fosse a mudança de shared_buffers. Como um exemplo, se o autovacuum for executado no ponto em que seu banco de dados de grande escala estiver em execução, ele diminuirá os resultados do teste. Um ponto de verificação começando como o teste começa também. Desligue o autovacuum para eliminá-lo do teste e ative os log_checkpoints para ver se está interferindo.

Uma terceira possibilidade, e isso eu tenho quase certeza que você está sofrendo de alguma forma, é que as coisas se movendo em disco podem causar uma desaceleração de 50% nos resultados. Os discos são cerca de duas vezes mais rápidos em suas partes iniciais do que os posteriores, e à medida que você executa o pgbench repetidamente, os dados são transferidos para as partes mais lentas à medida que você avança. Eu acabo reconstruindo todo o sistema de arquivos para obter resultados repetíveis, apenas uma maneira de ter certeza de que você está começando no mesmo ponto da unidade. Isso não afeta os resultados em escalas menores porque todos se encaixam na RAM.

Quando vejo uma alteração no desempenho depois de tocar em um parâmetro de configuração, sempre tento novamente a configuração original para garantir que essa seja a causa. Muitas vezes fico surpreso ao descobrir que o teste fica mais lento toda vez que você o executa, sendo essa diferença de velocidade de localização do disco uma fonte para esse problema.

    
por 11.05.2011 / 05:22