Hoy es la fecha límite para la tarifa de habitación especial en el hotel que albergará la Conferencia PostgreSQL Este 2010 de este mes. Si ha estado postergando la reserva de un lugar en la conferencia, a partir de mañana eso comenzará a costarle.
Mi charla es sobre evaluación comparativa de hardware de base de datos y está programada para la tarde del primer día, jueves 25 de marzo. Aquellos que hayan visto esta charla antes, ya sea en vivo en PGCon 2009 o a través del enlace de video disponible allí, se estarán preguntando si voy a sacar las mismas diapositivas y hablar de nuevo. No es el caso; Si bien la filosofía general de la charla ("no confíe en nadie, ejecute sus propios puntos de referencia") sigue siendo la misma, los ejemplos y la combinación de pruebas sugeridos se han actualizado para reflejar otro año de avances en hardware, trabajo de PostgreSQL y mi propia investigación durante ese año. tiempo. La situación de Intel frente a AMD en particular ha cambiado bastante, lo que requiere un nuevo conjunto de puntos de referencia de memoria para seguir realmente lo que está sucediendo ahora.
Y PostgreSQL 9.0 solucionó un problema importante que impedía que normalmente entregara resultados precisos en Linux, debido a una regresión del kernel que empeoró mucho una situación que ya era demasiado común:es fácil que un solo cliente de pgbench se convierta en el cuello de botella cuando se ejecuta, en lugar de que la propia base de datos. La revisión que hice para pgbench de subprocesos múltiples (que también puede ser pgbench de procesos múltiples en sistemas que no admiten subprocesos) sugirió una aceleración sólida de>30 % incluso en sistemas que no tenían la incompatibilidad del kernel malo. Las pruebas posteriores sugieren que se pueden necesitar fácilmente 8 pgbench para obtener el rendimiento completo incluso de los procesadores modernos y económicos en los kernels de Linux recientes. Voy a repasar exactamente cómo termina funcionando en tales sistemas, y cómo esta nueva función hace posible volver a usar pgbench como la forma principal de medir el rendimiento de la CPU que ejecuta la base de datos.
Recientemente, también realicé una actualización del repositorio git para pgbench-tools que agrega soporte operativo para PostgreSQL 8.4 y compatibilidad básica 9.0, y la próxima actualización incluirá soporte para la opción de subprocesos múltiples ahora que he mapeado cómo eso necesita trabajar Todo esto lleva a alguna parte. Una vez que tengamos medidas precisas para el rendimiento de PostgreSQL que están limitadas por la CPU en el lado del servidor, algo que no ha sido el caso a menudo durante más de dos años, nuevamente se convierten en una forma útil de monitorear las regresiones de rendimiento en la base de código de PostgreSQL. Las pruebas incluidas deberán expandirse para que cubran más eventualmente, pero por ahora hemos llegado a un punto en el que se puede usar pgbench para encontrar regresiones que afectan la rapidez con la que se ejecutan las declaraciones SELECT simples. Sé que funciona como se esperaba, porque cada vez que construyo PostgreSQL accidentalmente con aserciones, eso se detecta porque veo que la tasa de procesamiento promedio cae drásticamente.
Una vez que tengo un par de sistemas configurados aquí para probar tales regresiones, la pregunta es cómo automatizar lo que estoy haciendo y luego hacer lo mismo con una gama más amplia de comprobaciones de compilación. Idealmente, podría ver un gráfico del rendimiento promedio de SELECT cada día, desglosado por versión, de modo que cuando se introdujera una confirmación que lo redujera, sería inmediatamente obvio cuándo disminuyó el rendimiento. Este es el objetivo soñado para construir una granja de rendimiento similar a la granja de compilación de PostgreSQL. Las piezas están casi todas juntas ahora:mis partes de pgbench están terminando, las extensiones de buildfarm para que hable directamente con git están avanzando (no es un requisito, pero nadie que trabaje en este proyecto quiere usar CVS si podemos evitarlo) , y lo principal que falta en este momento es alguien que dedique tiempo a integrar lo que he estado haciendo en un cliente similar a buildfarm.
Y parece que ahora tenemos un patrocinador corporativo dispuesto a ayudar con esa parte del trabajo, a quien dejaré que se atribuya el mérito cuando hayamos terminado, y eso está programado para este verano. Espero que el desarrollo de PostgreSQL 9.1 y el backpatching de 9.0 se lleven a cabo con una granja de rendimiento inicial para protegerse contra las regresiones de rendimiento. Si podemos retrotraer el nuevo pgbench de subprocesos múltiples a versiones anteriores de PostgreSQL, también podríamos incluirlos en la mezcla. Ya tengo un backport del pgbench 8.3, que tiene muchas mejoras, lo mantengo solo para probar sistemas 8.2. Con pgbench como un módulo de contribución bastante independiente, es posible crear uno posterior diferente del resto del sistema, siempre y cuando no espere que existan también características de base de datos más nuevas.
Si eso es algo que le interesa, mi charla en la conferencia trazará los cimientos sobre los que espero que se construya. Independientemente, espero que pueda asistir a la conferencia y disfrutar de la larga lista de charlas que se presentan allí.
