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

Hola.
En relación a checkpoints wal file (736), esto supone que hay mucha
actividad de escritura (update, delete, insert) en ese periodo de tiempo.
Puedes revisar:
- Si hay alguna tarea programada que lance alguna conexión con tareas
(queries) al servidor de base de datos .
- Si los usuarios lanzan algunas queries especiales al servidor de base de
datos. Bien directamente o a través de la apliación.
- Puedes aumentar los logs de Postgres para registrar todas las consultas y
luego analizarlas frente a un periodo de actividad normal. NOTA: esto puede
suponer un alta crecimiento de los logs de Postgres, así que piénsalo
antes. Y puede no ser fácil comparar la información. Es el parámetro:

log_statement = 'all'

- Puedes dejar una tarea en el servidor que se ejecute cada minuto y que
vaya registrando en un fichero de texto las conexiones que hay en el
servidor. Así puedes ver si hay conexiones u otra información distintas
frente a un periodo de actividad normal.

select * from pg_stat_activity;

On Wed, Mar 6, 2019 at 7:01 AM Carlos T. Groero Carmona <ctonetg(at)gmail(dot)com>
wrote:

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