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

Horacio estuve revisando la informacion de SAR y el CPU se encontraba
ocioso en un 23%, lo que me llama la atencion significativamente, es que
solo se esta usando por debajo del 10% de la RAM, solo cuando estos eventos
suceden se utiliza un ~12% de la RAM
Tengo servidores de prueba y en pre-produccion que utilizan del 40% al 50%
de su RAM y no tienen un alto nivel de carga, sin embargo este servidor en
produccion que tiene 512GB de RAM tiene un aumento critico en el tiempo de
respuesta y la RAM solo se eleva hasta un ~11%.

No se si este dato tenga alguna relacion pero, cuando empece a trabajar
aqui el shared_buffers era de 8GB, el uso de la RAM era al 10%,
recientemente aumentamos el shared_buffers = 96GB y el uso de la RAM
disminuyo al ~5%, olo en eventos criticos la RAM aumenta a un ~11%, una vez
este evento termina el uso de la RAm disminuye a un ~5%

On Sat, Mar 2, 2019 at 4: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
>
>
>
>
>
>