Eu mantenho vários projetos cujo propósito na vida é facilitar o teste de partes do PostgreSQL. Todos eles receberam uma atualização decente na semana passada.
o dimensionamento de fluxo testa como a velocidade da memória aumenta nos servidores à medida que mais núcleos são ativados. São dados fascinantes, o suficiente para começar a ver algumas tendências reais. Ele agora funciona corretamente em sistemas com grandes quantidades de cache de CPU, porque eles têm muitos núcleos. Antes era possível ser tão agressivo com o dimensionamento do conjunto de teste para evitar o impacto do cache que usava mais memória do que poderia ser alocado com o design atual do código de fluxo. Isso foi redimensionado. Se você tiver um servidor de 48 núcleos ou maior, eu poderia usar mais alguns testes desse novo código para ver se a nova maneira de lidar com isso faz sentido.
peg é um script que escrevi para facilitar a compilação do PostgreSQL a partir do código-fonte, normalmente para trabalho de desenvolvedor ou para tentar temporariamente uma versão mais recente em um sistema de produção. Era muito fácil se confundir com a alternância entre projetos e suas ramificações git associadas antes; a documentação nesta área é muito melhorada.
O pgbench-tools é meu workhouse de teste de desempenho, permitindo que você enfileire dias de benchmark e tenha ferramentas de análise suficientes disponíveis para entender isso. O programa agora rastreia o parâmetro pg_stat_bgwriter.buffers_backend_fsync introduzido recentemente se você tiver uma versão que o suporte (atualmente apenas uma compilação recente – o que nos traz de volta ao motivo pelo qual o peg é útil). Você também pode dizer a ele para executar cada teste por um período fixo de tempo, o que torna muito mais fácil testar em valores de cliente/tamanho muito variados.
Quanto ao que você pode fazer com o pgbench-tools... a partir de hoje estou compartilhando os testes de benchmarking que estou fazendo no PostgreSQL 9.1 no servidor mais poderoso que tenho uso ilimitado. 8 núcleos, 16 GB de RAM, 3 unidades de banco de dados RAID-0 de disco, 1 volume WAL de disco, cache com bateria Areca. Você pode ver os resultados. As execuções são organizadas em conjuntos de teste, cada um dos quais representa algum tipo de alteração na configuração. Por exemplo, o número 1 nesses dados está executando apenas SELECT, o número 2 está executando como o TPC-B, mas com 8 GB de RAM e código anterior, enquanto o mais importante é o número 3, executando o TPC-B com 16 GB de RAM e código que rastreia buffers_backend_fsyncs.
Existem vários patches na fila do PostgreSQL 9.1 relacionados ao desempenho nas áreas destacadas por esses resultados – que o Linux pode ter latência de pior caso extremamente alta em cargas de banco de dados pesadas de gravação. Um bom exemplo médio é o teste 215: escala de 1000, 32 clientes, 365 TPS. Mas a latência do pior caso é de 43 segundos, e você pode ver os pontos mortos no gráfico TPS. Isso é simplesmente terrível, e existem alguns conceitos flutuando sobre como fazer exatamente isso.
Se alguém lendo isso tiver um servidor poderoso disponível por algumas semanas para executar testes como este, ficarei feliz em ajudá-lo a replicar esse ambiente e ver que tipo de resultados você vê. A única mágica que tenho é um pouco de prática em como definir o dimensionamento e as cargas do cliente para que você não perca muito tempo com testes improdutivos. O resto do meu processo é todo gratuito e documentado.
