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
