Una de las partes más útiles de
documentación de PostgreSQL en las que he trabajado es Tuning Your PostgreSQL
Server. Cuando se escribió en el verano de 2008, unos meses después del
lanzamiento de PostgreSQL 8.3, era difícil encontrar una guía similar que
fuera (relativamente) concisa y actualizada. Desde entonces, yo mismo y
muchos otros colaboradores de PostgreSQL hemos ayudado a mantener ese documento actualizado
a medida que se realizaban cambios en PostgreSQL.
La tendencia interesante y útil
durante ese período es que los parámetros siguen desapareciendo del conjunto
de los que debe preocuparse. En PostgreSQL 8.2, había una larga
lista de parámetros que probablemente necesitaba ajustar para obtener un buen rendimiento
en un servidor PostgreSQL:shared_buffers, eficaz_cache_size,
checkpoint_segments, autovacuum, max_fsm_pages,
default_statistics_target, work_mem, wal_buffers y (si se usa
partición) constrict_exclusion.
8.3 activó por defecto el vacío automático
con un comportamiento razonable, junto con la eliminación de algunos
parámetros de escritor de fondo que causaron nada más que problemas (nunca llegaron a estar en la lista). 8.4 eliminó la necesidad de los dos
parámetros max_fsm_*, aumentó default_statistics_target a un valor inicial mucho
mejor e hizo que la configuración de la restricción_exclusión
no fuera necesaria en los casos más comunes. Son seis parámetros menos
que es probable que necesite ajustar.
Desafortunadamente, la versión 9.0 solo hizo
la configuración del servidor más complicada. Y los núcleos de Linux más nuevos incluso
retrocedieron el comportamiento predeterminado. A partir del kernel de Linux
2.6.33, el valor predeterminado elegido para wal_sync_method cambió a
open_datasync. Esto resulta tener terribles
implicaciones de rendimiento para PostgreSQL, particularmente cuando se combina con la baja
configuración predeterminada para wal_buffers en el servidor.
Pero la marcha hacia un mejor comportamiento por defecto
se reanudó recientemente para lo que eventualmente se planea que sea
PostgreSQL 9.1. Durante el último CommitFest, Marti
Raudsepp creó un parche para solucionar el problema de wal_sync_method
después de algunas discusiones fuertes sobre qué forma debería tomar ese cambio.
Descubrir que este cambio de comportamiento rompió PostgreSQL por completo
cuando se ejecutaba en ext4 con la opción “data=journal” ayudó
a decidir qué hacer aquí de forma predeterminada.
Dos parámetros que no recomiendo
tocar en la mayoría de los casos son commit_siblings y commit_delay,
artefactos de un intento anterior de mejorar el rendimiento en sistemas con
tiempos de confirmación lentos (que incluye la mayoría de los sistemas que no tienen una
caché de escritura respaldada por batería para acelerar esa área). Hoy en día
desactivar el parámetro synchronous_commit introducido en 8.3 es
mucho más probable que ayude aquí. Si bien es poco probable que mejoren el rendimiento
, las personas que intentan configurarlos han sufrido más de lo necesario
por las desventajas de esa decisión. El comportamiento del peor de los casos
aquí se mejoró considerablemente en un parche que escribí para optimizar cómo se ejecuta la lógica que controlan esos parámetros.
Y esta semana, el último parámetro
que se eliminará efectivamente en la mayoría de los casos es wal_buffers. Yo
sugerí un cambio para establecer esto automáticamente como un porcentaje del tamaño (alrededor del 3%)
asignado a los parámetros shared_buffers, que normalmente son mucho más grandes.
Esto establece el valor de wal_buffers en el límite superior normal de su
rango efectivo, 16 MB, una vez que haya asignado al menos 512 MB a
shared_buffers. Y si ha aumentado shared_buffers desde su minúsculo
valor predeterminado, obtendrá una mejora correspondiente en este
importante parámetro de rendimiento de confirmación. Tendrá que esforzarse
en su camino para romper la configuración de este parámetro para llegar a las malas
situaciones posibles en versiones anteriores.
Siempre es menos complicado tener la cantidad de configuración que
necesita hacer en el servidor de forma predeterminada
vale la pena, y ver que los parámetros desaparecen de la lista crítica es
un cambio bienvenido. ¿Que sigue? Los problemas centrales con la asignación de
memoria compartida en sistemas operativos derivados de UNIX, particularmente Linux,
hacen que sea muy difícil eliminar los búferes compartidos. Y las preocupaciones
sobre el control total del sistema por parte del servidor limitan la capacidad
de establecer automáticamente parámetros como work_mem en el rango correcto.
Se han presentado algunas propuestas para administrar mejor el grupo de memoria de trabajo
sugerido, para que uno pueda ver alguna mejora.
El siguiente parámetro que tengo en mente es
checkpoint_segments. Después de agregar solo inicio de sesión adicional en esta área en
el último CommitFest, hay algunas mejoras en esta área que se acercan
a confirmar ahora para mejorar realmente el comportamiento del punto de control. Espero
cambiar eventualmente el ajuste del punto de control para controlarlo estrictamente
a través de parámetros orientados al tiempo, en lugar de requerir que los usuarios
entiendan la mecánica de cómo funciona el registro de escritura anticipada para ajustar el
sistema. Todavía hay demasiadas situaciones feas posibles aquí para hacer eso
a tiempo para 9.1, pero configurar el recuento de segmentos automáticamente es
factible para apuntar a 9.2.
