He publicado múltiples puntos de referencia comparando diferentes versiones de PostgreSQL, como por ejemplo la charla de arqueología del rendimiento (evaluando PostgreSQL 7.4 hasta 9.4), y todos esos puntos de referencia asumidos como entorno fijo (hardware, kernel, …). Lo cual está bien en muchos casos (p. ej., cuando se evalúa el impacto en el rendimiento de un parche), pero en la producción esas cosas cambian con el tiempo:obtiene actualizaciones de hardware y, de vez en cuando, obtiene una actualización con una nueva versión del kernel.
Para las actualizaciones de hardware (mejor almacenamiento, más RAM, CPU más rápidas, …), el impacto suele ser bastante fácil de predecir y, además, las personas generalmente se dan cuenta de que necesitan evaluar el impacto analizando los cuellos de botella en la producción y tal vez incluso probando el nuevo hardware primero. .
Pero, ¿qué pasa con las actualizaciones del kernel? Lamentablemente, por lo general no hacemos muchas evaluaciones comparativas en esta área. La suposición es principalmente que los kernels nuevos son mejores que los antiguos (más rápidos, más eficientes, escalables a más núcleos de CPU). ¿Pero es realmente cierto? ¿Y qué tan grande es la diferencia? Por ejemplo, ¿qué pasa si actualiza un kernel de 3.0 a 4.7? ¿Afectará eso al rendimiento y, en caso afirmativo, mejorará el rendimiento o no?
De vez en cuando recibimos informes sobre regresiones graves con una versión de kernel en particular, o mejoras repentinas entre versiones de kernel. Claramente, las versiones del kernel pueden afectar el rendimiento.
Soy consciente de un solo punto de referencia de PostgreSQL que compara diferentes versiones del kernel, realizado en 2014 por Sergey Konoplev en respuesta a las recomendaciones para evitar los kernels 3.0 - 3.8. Pero ese punto de referencia es bastante antiguo (la última versión del kernel disponible hace unos 18 meses era la 3.13, mientras que hoy en día tenemos 3.19 y 4.6), así que he decidido ejecutar algunos puntos de referencia con los núcleos actuales (y PostgreSQL 9.6beta1).
PostgreSQL vs. versiones del kernel
Pero primero, permítanme discutir algunas diferencias significativas entre las políticas que rigen las confirmaciones en los dos proyectos. En PostgreSQL tenemos el concepto de versiones principales y secundarias:las versiones principales (por ejemplo, 9.5) se publican aproximadamente una vez al año e incluyen varias funciones nuevas. Las versiones menores (p. ej., 9.5.2) solo incluyen correcciones de errores y se publican aproximadamente cada tres meses (o con mayor frecuencia, cuando se descubre un error grave). Por lo tanto, no debería haber cambios importantes en el rendimiento o el comportamiento entre las versiones secundarias, lo que hace que sea bastante seguro implementar versiones secundarias sin pruebas exhaustivas.
Con las versiones del kernel, la situación es mucho menos clara. El kernel de Linux también tiene ramas (por ejemplo, 2.6, 3.0 o 4.7), que de ninguna manera son iguales a las "versiones principales" de PostgreSQL, ya que continúan recibiendo nuevas funciones y no solo correcciones de errores. No estoy afirmando que la política de control de versiones de PostgreSQL sea de alguna manera automáticamente superior, pero la consecuencia es que la actualización entre versiones menores del kernel puede afectar significativamente el rendimiento o incluso introducir errores (por ejemplo, 3.18.37 sufre problemas de OOM debido a una corrección de errores confirmar).
Por supuesto, las distribuciones se dan cuenta de estos riesgos y, a menudo, bloquean la versión del kernel y realizan más pruebas para eliminar nuevos errores. Esta publicación, sin embargo, utiliza núcleos vainilla a largo plazo, disponibles en www.kernel.org.
Valor de referencia
Hay muchos puntos de referencia que podríamos usar:esta publicación presenta un conjunto de pruebas de pgbench, es decir, un punto de referencia OLTP (similar a TPC-B) bastante simple. Planeo hacer pruebas adicionales con otros tipos de pruebas comparativas (particularmente orientadas a DWH/DSS) y las presentaré en este blog en el futuro.
Ahora, volviendo al pgbench:cuando digo "colección de pruebas" me refiero a combinaciones de
- solo lectura frente a lectura y escritura
- tamaño del conjunto de datos:el conjunto activo (no) cabe en los búfer/RAM compartidos
- recuento de clientes:un solo cliente frente a muchos clientes (bloqueo/programación)
Los valores obviamente dependen del hardware utilizado, así que veamos en qué hardware se estaba ejecutando esta ronda de pruebas comparativas:
- CPU:Intel i5-2500k a 3,3 GHz (3,7 GHz turbo)
- RAM:8 GB (DDR3 a 1333 MHz)
- almacenamiento:6x Intel SSD DC S3700 en RAID-10 (Linux sw raid)
- sistema de archivos:ext4 con programador de E/S predeterminado (cfq)
Por lo tanto, es la misma máquina que he usado para varios puntos de referencia anteriores:una máquina bastante pequeña, no exactamente la CPU más nueva, etc., pero creo que sigue siendo un sistema "pequeño" razonable.
Los parámetros de referencia son:
- escalas del conjunto de datos:30, 300 y 1500 (aproximadamente 450 MB, 4,5 GB y 22,5 GB)
- número de clientes:1, 4, 16 (la máquina tiene 4 núcleos)
Para cada combinación hubo 3 ejecuciones de solo lectura (15 minutos cada una) y 3 ejecuciones de lectura y escritura (30 minutos cada una). El guión real que impulsa el punto de referencia está disponible aquí (junto con los resultados y otros datos útiles).
Nota :si tiene un hardware significativamente diferente (por ejemplo, unidades rotativas), es posible que vea resultados muy diferentes. Si tiene un sistema que le gustaría probar, hágamelo saber y lo ayudaré con eso (suponiendo que se me permita publicar los resultados).
Versiones del núcleo
En cuanto a las versiones del kernel, he probado las últimas versiones en todas las ramas a largo plazo desde 2.6.x (2.6.39, 3.0.101, 3.2.81, 3.4.112, 3.10.102, 3.12.61, 3.14.73, 3.16. 36, 3.18.38, 4.1.29, 4.4.16, 4.6.5 y 4.7). Todavía hay muchos sistemas que se ejecutan en kernels 2.6.x, por lo que es útil saber cuánto rendimiento puede ganar (o perder) al actualizar a un kernel más nuevo. Pero he estado compilando todos los kernels por mi cuenta (es decir, usando kernels de vainilla, sin parches específicos de distribución), y los archivos de configuración están en el repositorio de git.
Resultados
Como de costumbre, todos los datos están disponibles en bitbucket, incluidos
- archivo .config del núcleo
- secuencia de comandos de referencia (run-pgbench.sh)
- Configuración de PostgreSQL (con algunos ajustes básicos para el hardware)
- Registros de PostgreSQL
- varios registros del sistema (dmesg, sysctl, mount,...)
Los siguientes gráficos muestran los tps promedio para cada caso de referencia:los resultados de las tres ejecuciones son bastante consistentes, con una diferencia de ~2 % entre el mínimo y el máximo en la mayoría de los casos.
solo lectura
Para el conjunto de datos más pequeño, hay una clara caída de rendimiento entre 3,4 y 3,10 para todos los recuentos de clientes. Los resultados para 16 clientes (4 veces la cantidad de núcleos), sin embargo, más que se recupera en 3.12.
Para el conjunto de datos mediano (encaja en la RAM pero no en los búferes compartidos), podemos ver la misma caída entre 3.4 y 3.10 pero no la recuperación en 3.12.
Para grandes conjuntos de datos (que superan la memoria RAM, con mucha carga de E/S), los resultados son muy diferentes:no estoy seguro de lo que sucedió entre 3.10 y 3.12, pero la mejora del rendimiento (particularmente para un mayor número de clientes) es bastante asombrosa.
lectura-escritura
Para la carga de trabajo de lectura y escritura, los resultados son bastante similares. Para los conjuntos de datos pequeños y medianos, podemos observar la misma caída de ~10 % entre 3.4 y 3.10, pero lamentablemente no hay recuperación en 3.12.
Para el gran conjunto de datos (nuevamente, significativamente limitado por E/S), podemos ver una mejora similar en 3.12 (no tan significativa como para la carga de trabajo de solo lectura, pero aún significativa):
Resumen
No me atrevo a sacar conclusiones de un solo punto de referencia en una sola máquina, pero creo que es seguro decir:
- El rendimiento general es bastante estable, pero podemos ver algunos cambios de rendimiento significativos (en ambas direcciones).
- Con conjuntos de datos que caben en la memoria (ya sea en búferes compartidos o al menos en la RAM), observamos una disminución medible del rendimiento entre 3,4 y 3,10. En la prueba de solo lectura, esto se recupera parcialmente en 3.12 (pero solo para muchos clientes).
- Con conjuntos de datos que exceden la memoria y, por lo tanto, principalmente vinculados a E/S, no vemos ninguna caída de rendimiento, sino una mejora significativa en 3.12.
En cuanto a las razones por las que ocurren esos cambios repentinos, no estoy muy seguro. Hay muchas confirmaciones posiblemente relevantes entre las versiones, pero no estoy seguro de cómo identificar la correcta sin pruebas extensas (y que consumen mucho tiempo). Si tiene otras ideas (p. ej., está al tanto de tales compromisos), hágamelo saber.
