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 <lucasluen...@gmail.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 <hmira...@gmail.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 >> >> >> >> >> >>
