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

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 <http://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
>
>
>
>
>