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

Si puedes corre un pgtune https://pgtune.leopard.in.ua/#/

No pongas más de la mitad de la RAM si lo haces debes ajustar el
/dev/shm ( que es la mitad de la RAM por defecto ).

vacuum soporta jobs en parallelo ( ignoro si por defecto corre en
parallelo ) pero un buen numero es algo como el numero de los cores (
alguien con más experiencia puede indicar un numero ) si el vacuum es
como compilar en Linux n * 2 + 1 es el numero ( n es el numero de
threads ). ( pero no creo ). hay que probar ahi.

Lo que debes mirar en el SAR siempre son las contenciones del disco, el
uso del SWAP ( intercambio de hecho ), por ejemplo puedes tener 100% del
swap usado, pero si no hay page-in o page-out da lo mismo, el
page-in/out es movimiento entre la SWAP y la RAM... ese es el valor
importante.

Trata de ver las consultas que se demoran más de 10 segundos, en lo
personal hago sintonía fina de las bases de datos en las siguientes
iteraciones.

1.- consultas más de 10 min.

2.- consultas más de 1 min.

3.- consultas más de 10 segundos.

4.- consultas final, más de 3 segundos.

Revisa el proyecto dexter, lo estoy usando y ayuda un poco a crear
indices basicos. https://github.com/ankane/dexter

Sobre tu problema puntual, por la RAM que me dices que tines asumo que
es una maquina real, sí es disco local asegurate que los discos esten
bien y que no hay alertas ( que marca es el servidor y que modelo ) si
es un HP tengo scripts que me dicen el estado de los discos y controladora.

Revisa si las dos fuentes esten conectadas en el servidor o tres (
depende del modelo ), sí una fuente no esta conectada, el cache se va a
desconectar para proteger los datos ( esto lo ví en Oracle Corp en una
DELL de tres fuentes, solo una fuente estaba conectada, era un demo y se
asumio que estaba bien por que estaba funcionando, no sabían que esas
maquinas desconectan el cache cuando una fuente esta muerta ( para el
caso de usa solo una fuente y usar el cache es mejor sacar la fuente ),
así trabajan los servidores por diseño.

On 6/03/2019 7:10 PM, Carlos T. Groero Carmona wrote:
> 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
> <mailto: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 <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
>>
>>
>>
>>
>>