Después de Tuning Linux para baja latencia de PostgreSQL del mes pasado, ahora se ha realizado una gran cantidad de pruebas en dos sistemas de archivos, tres parches y dos conjuntos de parámetros de ajuste del kernel ejecutados. El resultado hasta ahora son algunos datos nuevos e interesantes, y una mejora más comprometida en esta área que ahora se encuentran en PostgreSQL 9.1 (haciendo tres en total, los otros dos son parches de monitoreo). Hablaré sobre la práctica recomendada el próximo mes durante una de mis charlas en PostgreSQL East, y también presenté algo en esta área para la PGCon de mayo. Aquí también hablaré un poco más sobre los callejones sin salida, mientras esos recuerdos aún están frescos.
El problema básico aquí es que la forma en que PostgreSQL usa el caché del sistema operativo al escribir permite que se acumulen grandes cantidades de datos. El resultado cuando finalizan los puntos de control de la base de datos pueden ser largas demoras mientras se espera que se escriban los datos. Resulta que el programa pgbench que viene con PostgreSQL es realmente bueno para crear este problema, así que eso es lo que usé para todas las pruebas. Las preguntas de medios que me propuse responder fueron:
- ¿El cambio del antiguo sistema de archivos ext3 realmente muestra una mejora en el rendimiento de las tareas de la base de datos? Escribí algo sobre el regreso de XFS en Linux el año pasado que mostró una buena mejora en los puntos de referencia simples. Sin embargo, eso no siempre se traduce en mejoras en la base de datos.
- ¿Los parámetros ajustables recientes de Linux dirty_bytes y dirty_background_bytes realmente mejoran la latencia en el peor de los casos?
- ¿Cuáles de los cambios de base de datos sugeridos aquí para mejorar el comportamiento realmente funcionan?
Puede ver todos los resultados de las pruebas si desea consultar los datos sin procesar. Lo que se cambió para cada conjunto de prueba está documentado, y si profundiza en una prueba individual, puede ver los parámetros de la base de datos utilizados y otra información básica del sistema operativo. Esa página web es lo que sale de mi programa de prueba pgbench-tools, si desea probar este tipo de cosas usted mismo.
Los resultados no fueron muy sorprendentes, pero fueron interesantes. Todas las pruebas aquí se realizaron con dos tamaños de base de datos. Con un tamaño de base de datos más pequeño (escala =500, aproximadamente una base de datos de 8 GB que cabe fácilmente en los 16 GB de RAM del servidor), ext3 administró 690 transacciones por segundo, mientras que con el doble de ese tamaño (escala =1000, aproximadamente una base de datos de 16 GB) fue mucho más busca atado y solo logró 349 TPS. XFS aumentó esos dos números a 1757 TPS y 417 TPS, una ganancia de 255% y 19%, respectivamente. Aún mejor, la latencia en el peor de los casos para una sola transacción se redujo del rango de 34 a 56 segundos (!) a 2 a 5 segundos. Si bien incluso 5 segundos no es bueno, esta es una carga de trabajo sintética diseñada para hacer que este problema sea realmente malo. Los números ext3 son tan terribles que aún es muy probable que se encuentre con un problema desagradable aquí, aunque en realidad estaba viendo un mejor comportamiento en ese sistema de archivos que en kernels anteriores (esto se hizo con 2.6.32).
Ronda 1:XFS gana de forma aplastante. No puedo recomendar ext3 como un sistema de archivos viable en sistemas Linux con mucha memoria si planea escribir mucho; simplemente no funciona en ese contexto. Este servidor solo tenía 16 GB de RAM, por lo que puede imaginar lo grave que es este problema en un servidor de producción serio aquí en 2011.
A continuación, los parámetros ajustables dirty_bytes y dirty_background_bytes. Estos dos mejoraron bastante la latencia en ext3, a expensas de algunas ralentizaciones. Lo peor de eso, el tiempo de mantenimiento lento al ejecutar VACUUM, no se ve en los resultados de las pruebas en sí; Ya hablé de eso en mi anterior entrada de blog. En XFS, ajustar estos parámetros es un desastre de rendimiento. En la escala de base de datos más pequeña, el rendimiento de TPS cae un 46 % y, además, la latencia empeora.
Ronda 2:no esperes ningún milagro de los bytes sucios o los bytes sucios de fondo. Parece que tienen algún efecto positivo en algunas circunstancias, pero la desventaja potencial también es grande. Asegúrese de probar cuidadosamente e incluya VACÍO en su prueba, antes de ajustar estos dos a la baja.
A continuación, terminé evaluando tres ideas de parches para PostgreSQL como parte de este último CommitFest:
- Difundir llamadas de punto de control de sincronización al disco (fsync) a lo largo del tiempo. Hemos visto cierto éxito con eso en un servidor de cliente ocupado cuando se combina con un manejo mejorado de cómo la base de datos almacena en caché otras operaciones de sincronización
- Solicitudes fsync compactas. Esta idea surgió de la primera y se convirtió en un parche escrito por Robert Haas. La idea es que los clientes que intenten sincronizar datos en el disco puedan estar compitiendo con la escritura del punto de control. Lo que hace el parche es permitir que los clientes limpien la cola de solicitudes fsync si alguna vez la encuentran llena.
- Ordenar las escrituras del punto de control. El concepto es que si escribe las cosas en el orden en que la base de datos cree que están almacenadas en el disco, el sistema operativo podría escribir de manera más eficiente. Este parche apareció hace algunos años con algunos resultados de referencia que sugerían que funcionaba, pero en ese momento nadie pudo replicar las mejoras. La idea encajaba lo suficientemente bien con el resto del trabajo que la evalué de nuevo.
Ronda 3:después de semanas de probar todo esto, el único enfoque de este conjunto que mostró la mejora en casi todos los tamaños de carga de trabajo fue el de compactación fsync. El código de sincronización del punto de control de propagación original ayudó un poco en esta área, pero la implementación específica que ahora está comprometida para 9.1 funcionó aún mejor. Fue una ganancia casi general del 10% en la mayoría de las pruebas de escritura pesada que realicé. Esa es una gran mejora para PostgreSQL 9.1, y debería eliminar por completo un problema que hemos visto que causa una ralentización mucho mayor en los sistemas de producción aquí.
El resto de las ideas aquí no obtuvieron una evaluación tan positiva después de mucho evaluación comparativa, así que por ahora esos vuelven al estante. Continuaré reuniendo datos aquí (algunas pruebas ext4 son lo siguiente lógico a intentar) y luego volveré al desarrollo nuevamente. Obtener una ganancia del 10 % en algunas cargas de trabajo difíciles es ciertamente bueno, pero todavía hay demasiados comportamientos en el peor de los casos aquí para considerar los problemas de sincronización de puntos de control como un tema cerrado.
