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 <cton...@gmail.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 <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 >>> >>> >>> >>> >>> >>>
