Mantengo una serie de proyectos cuyo propósito en la vida es hacer que probar partes de PostgreSQL sea más fácil. Todos estos obtuvieron una actualización decente durante la última semana.
el escalado de flujo prueba cómo aumenta la velocidad de la memoria en los servidores a medida que se ponen en juego más núcleos. Son datos fascinantes, suficientes para comenzar a ver algunas tendencias reales. Ahora funciona correctamente en sistemas con grandes cantidades de caché de CPU, porque tienen muchos núcleos. Antes era posible que fuera tan agresivo con el tamaño del conjunto de prueba para evitar el impacto de la memoria caché que usaba más memoria de la que podía asignarse con el diseño actual del código de flujo. Eso ha sido reducido. Si tiene un servidor de 48 núcleos o más, me vendría bien probar más este nuevo código para ver si la nueva forma en que manejo esto tiene sentido.
peg es un script que escribí para facilitar la compilación de PostgreSQL desde el código fuente, generalmente para el trabajo del desarrollador o para probar temporalmente una versión más nueva en un sistema de producción. Antes era muy fácil confundirse con el cambio entre proyectos y sus ramas de git asociadas; la documentación en esta área ha mejorado mucho.
pgbench-tools es mi casa de trabajo de pruebas de rendimiento, lo que le permite poner en cola días de referencia y luego tener suficientes herramientas de análisis disponibles para darle sentido. El programa ahora rastrea el parámetro pg_stat_bgwriter.buffers_backend_fsync recientemente introducido si tiene una versión que lo admite (actualmente solo una compilación soure reciente, lo que nos lleva de nuevo a por qué peg es útil). También puede indicarle que ejecute cada prueba durante un período de tiempo fijo, lo que hace que las pruebas en valores de tamaño/cliente que varían enormemente sean mucho más fáciles.
En cuanto a lo que puede hacer con pgbench-tools... a partir de hoy, ahora estoy compartiendo las pruebas comparativas que estoy haciendo en PostgreSQL 9.1 en el servidor más poderoso del que tengo uso ilimitado. 8 núcleos, 16 GB de RAM, 3 unidades de base de datos RAID-0 de disco, 1 volumen WAL de disco, caché respaldada por batería Areca. Puedes ver los resultados. Las ejecuciones se organizan en conjuntos de prueba, cada uno de los cuales representa algún tipo de cambio en la configuración. Por ejemplo, el n.° 1 en estos datos solo ejecuta SELECT, el n.° 2 ejecuta un TPC-B similar pero con 8 GB de RAM y un código más antiguo, mientras que el elemento interesante es el n.° 3, que ejecuta TPC-B con 16 GB de RAM y un código que rastrea buffers_backend_fsyncs.
Hay varios parches en la cola de PostgreSQL 9.1 relacionados con el rendimiento en las áreas resaltadas por estos resultados:que Linux puede tener una latencia extremadamente alta en el peor de los casos en cargas de base de datos con muchas escrituras. Un buen ejemplo promedio es la prueba 215:escala de 1000, 32 clientes, 365 TPS. Pero la latencia en el peor de los casos es de 43 segundos y puede ver los puntos muertos en el gráfico de TPS. Eso es simplemente terrible, y hay algunos conceptos dando vueltas sobre cómo hacer precisamente eso.
Si alguien que lea esto tiene un servidor potente disponible durante algunas semanas para ejecutar pruebas como esta, me complacería ayudarlo a replicar este entorno y ver qué tipo de resultados ve. La única magia que tengo es algo de práctica sobre cómo configurar la escala y las cargas de los clientes para que no pierda mucho tiempo en pruebas improductivas. El resto de mi proceso es gratuito y está documentado.
