Re: El rendimiento de postgres puede ser afectado por checkpoint_segments?

Hola.

checkpoint_segments indica el número de ficheros de log entre checkpoints
automáticos del log de transacciones.
Por defecto por ejemplo en 9.3 son 3 ficheros.

En sí mismo este valor no afecta al rendimiento de forma directa. Pero hay
que tenerlo en cuenta porque en sistema de un número alto de escrituras, el
valor que viene puede ser demasiado pequeño, provocando checkpoints
demasiado frecuentemente, lo cual supone una actividad de disco extra, lo
cual puede producir algún problema de rendimiento.

Yo creo que puede ser de ayuda activar el log de checkpoint.

log_checkpoints = on

De esta manera, puedes ver la actividad de los checkpoint, y ver si es o no
suficiente el tamaño establecido y los momentos en los que salta de manera
automática, e intentar relacionarlo con los momentos de bajo rendimiento.

Éste artículo quizás puede ser de interés:
https://blog.2ndquadrant.com/basics-of-tuning-checkpoints/

On Sat, Mar 2, 2019 at 11:57 PM Horacio Miranda <hmiranda(at)gmail(dot)com> wrote:

> Revisa SAR para ver que esta pasando con la CPU y los discos.
>
> Si quieres saber lo que pasa cada minuto, cambia el sar de 10 min sample a
> 1 min.
> On 1/03/2019 7:10 AM, Carlos T. Groero Carmona wrote:
>
> Hola lista,
>
> Hace unas semanas les comente que estaba teniendo problemas de rendimiento
> en mi servidor, pero este problema pasa generalmente los viernes (cierre de
> semana) y los cierres de quincena (1, 15 y ultimo dia del mes). El resto
> del tiempo funciona maravillosamente bien.
>
> Por ejemplo, hoy es 28 ultimo dia del mes, he tenido algunos peak en el
> rendimiento de postgres, que han estado afectado por autovacuum, cada vez
> que autovacuum esta trabajando en tablas en las cuales se esta escribiendo
> en ese momento y se detiene mucho tiempo, pues se ve afectado el
> rendimiento de postgres.
>
> EL valor actual de mi autovacuum_vacuum_cost_limit = 200 y
> mi autovacuum_max_workers = 6
> El viernes pasado la tarde, aumente el cost_limit a 800 y estuvo todo el
> fin de semana sin problemas, pero el lunes alrededor de las 11 am obtuve
> una alerta donde el tiempo de respuesta aumento considerablemente, lo
> disminui a 400 y siguio el problema asi que tuve que disminuirlo a 200
> nuevamente y todo se tranquilizo.
>
> Por lo que me da a pensar que podria estar enfrentando un problema con el
> uso de I/O.
>
> Lo que me llama la atention que el checkpoint_segments = 2048 cuando
> pgTune me indica que para un DW debe seria ser 128 y para OLTP deberia ser
> 64.
>
> Segun wiki.postgresql.org en su articulo aserca de optimizar la
> configuracion de tu servidor, comenta que valores alto en
> el checkpoint_segments usaran mayor cantidad de disco: "(...) For more
> write-heavy systems, values from 32 (checkpoint every 512MB) to 256 (every
> 4GB) are popular nowadays. *Very large settings use a lot more disk and
> will cause your database to take longer to recover* (...)"
>
> Algo curioso tambien que me ocurrio hace unas dos semanas atr'as y puede
> estar relacionado con esto, es que ejecute un manual vacuum a mi base de
> datos de produccion en la madrugada cuando la carga es mas baja, pero se
> ejecuto un cron job y empezo a importar data desde unos archivos, en el
> proceso postgres mostro un *out of shared memory *por lo que estoy
> planeando aumentar el shared buffer nuevamente a 64GB teniendo en cuenta
> que mi servidor es dedicado solo a postgres, tiene 512GB de RAm y shmmax es
> the 125GB. En el proceso se perdio parte de la data (despues se recupero de
> otra parte) y coinsidio cada vez que se guardo en el log un *out of
> shared memory*,
> NOte: en uno de los logs encontre que el buffer usado para un checkpoint
> fue de 17.5%, normalmente rondea el 10%
>
> Entonces mi pregunta es, puede este valor tan alto de checkpoint_segments
> afectar el uso de I/O, reflejandose en los procesos de vacuum, autovacuum y
> en la performance de mi servidor?
>
> Abajo algunos valores de mi configuration:
>
> checkpoint_segments = 2048
>
> checkpoint_timeout = 60min
>
> checkpoint_completion_target = 0.9
>
> hared_buffers = 24GB
>
> work_mem = 128MB
>
> maintenance_work_mem = 4GB
>
> random_page_cost = 4.0
>
> effective_io_concurrency = 1
>
>
>
> Una vez mas gracias por cualquier correccion o sugerencia.
>
>
> Saludos,
>
> Carlos
>
>
>
>
>
>