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 <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 > > > > > >
