Hoje é o prazo para a tarifa especial do quarto no hotel que hospeda a Conferência PostgreSQL Leste 2010 deste mês. Se você está procrastinando para reservar um lugar na conferência, a partir de amanhã isso começará a custar-lhe.
Minha palestra é sobre Database Hardware Benchmarking e está marcada para o final da tarde do primeiro dia, quinta-feira, 25 de março. Quem já viu essa palestra antes, seja ao vivo na PGCon 2009 ou pelo link de vídeo disponível lá, pode estar se perguntando se vou arrastar os mesmos slides e falar novamente. Não é o caso; embora a filosofia geral da palestra (“não confie em ninguém, execute seus próprios benchmarks”) permaneça a mesma, os exemplos e o mix de testes sugeridos foram atualizados para refletir mais um ano de avanços de hardware, trabalho do PostgreSQL e minha própria pesquisa durante esse período Tempo. A situação Intel vs. AMD em particular mudou bastante, exigindo um novo conjunto de benchmarks de memória para realmente acompanhar o que está acontecendo agora.
E o PostgreSQL 9.0 corrigiu um grande problema que o impedia de fornecer resultados normalmente precisos no Linux, devido a uma regressão do kernel que piorou muito uma situação já muito comum:é fácil para um único cliente pgbench se tornar o gargalo ao executá-lo, em vez de do que o próprio banco de dados. A revisão que fiz para o pgbench multi-thread (que também pode ser pgbench multi-processo em sistemas que não suportam threads) sugeriu uma aceleração sólida de mais de 30%, mesmo em sistemas que não tinham a incompatibilidade de kernel ruim neles. Testes subsequentes sugerem que pode levar facilmente 8 processos pgbench para obter a taxa de transferência total até mesmo de processadores modernos baratos em kernels Linux recentes. Examinarei exatamente como isso acaba acontecendo em tais sistemas e como esse novo recurso torna possível usar novamente o pgbench como a principal maneira de medir o desempenho da CPU executando o banco de dados.
Recentemente, também atualizei o repositório git para pgbench-tools que adiciona suporte funcional para compatibilidade PostgreSQL 8.4 e 9.0 básica, e a próxima atualização incluirá suporte para a opção multi-threaded agora que mapeei como isso precisa trabalhar. Isso tudo está levando a algum lugar. Uma vez que temos medições precisas para o desempenho do PostgreSQL que são limitadas pela CPU no lado do servidor, algo que não tem sido o caso há mais de dois anos, essas medidas novamente se tornam uma maneira útil de monitorar regressões de desempenho na base de código do PostgreSQL. Os testes incluídos precisarão ser expandidos para cobrir mais eventualmente, mas por enquanto chegamos a um ponto em que o pgbench pode ser usado para encontrar regressões que afetam a rapidez com que as instruções SELECT simples são executadas. Eu sei que funciona como esperado, porque toda vez que eu acidentalmente construo o PostgreSQL com asserções, isso é pego porque vejo a taxa média de processamento cair drasticamente.
Depois de configurar alguns sistemas aqui para testar essas regressões, a questão se torna como automatizar o que estou fazendo e, em seguida, fazer a mesma coisa em uma variedade maior de check-outs de construção. Idealmente, você seria capaz de ver um gráfico do desempenho médio do SELECT a cada dia, dividido por versão, de modo que, quando um commit que o reduzisse, fosse imediatamente óbvio quando o desempenho caísse. Esse é o objetivo dos sonhos para construir um farm de desempenho semelhante ao buildfarm do PostgreSQL. As peças estão quase todas juntas agora: minhas partes do pgbench estão terminando, extensões para o buildfarm para fazê-lo falar diretamente com o git estão avançando (não é um requisito, mas ninguém trabalhando neste projeto quer usar o CVS se pudermos evitá-lo) , e a principal coisa que falta neste momento é alguém para dedicar tempo para integrar o que tenho feito em um cliente do tipo buildfarm.
E parece que agora temos um patrocinador corporativo disposto a ajudar com essa parte do trabalho, por quem deixarei o crédito quando terminarmos, e isso está programado para acontecer neste verão. Espero totalmente que o desenvolvimento do PostgreSQL 9.1 e o backpatching do 9.0 aconteçam com um farm de desempenho inicial para proteger contra regressões de desempenho. Se pudermos fazer backport do novo pgbench multi-threaded para versões mais antigas do PostgreSQL, podemos incluí-los no mix também. Já tenho um backport do pgbench 8.3, que tem muitas melhorias, mantenho apenas para testar sistemas 8.2. Com o pgbench como um módulo de contribuição bastante autônomo, é possível construir um posterior diferente do resto do sistema, desde que não espere que novos recursos de banco de dados existam também.
Se isso é algo em que você está interessado, minha palestra na conferência vai mapear as bases sobre as quais espero que seja construída. Independentemente disso, espero que você possa comparecer à conferência e aproveitar a longa lista de palestras que estão sendo apresentadas lá.
