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

Lucas, gracias por su consejo y bibliografia, estuve revisando.
Aprovechando que tengo
log_checkpoints = on

Hice un analisis the los reportes echos con pgBadger

Checkpoints:
El numero de echeckpoints buffers no se relaciona con el horario donde tuve
un rendimiento lento, ahora el peakde checkpoints wal file (736) si se
relaciona y es casi el el doble de el peack de un domingo (476)

Pero algo a lo que nunca habia prestado atencion y surgio ahora es:
Prepared queries ratio.
El de un domingo:
Ratio of bind vs prepare: 162.00
Ratio between prepared and "usual" statements: 99.39%

El del viernes pasado:
Ratio of bind vs prepare: 21.94
Ratio between prepared and "usual" statements: 1.57%

Esto lo acabo de encontrar y no le habia prestado la atencion correcta a
estos indices anteriormente.

On Tue, Mar 5, 2019 at 3:06 PM Lucas Luengas <lucasluengas(at)gmail(dot)com> wrote:

> 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
>>
>>
>>
>>
>>
>>