From: | "Carlos T(dot) Groero Carmona" <ctonetg(at)gmail(dot)com> |
---|---|
To: | Lista PostgreSql <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | El rendimiento de postgres puede ser afectado por checkpoint_segments? |
Date: | 2019-02-28 18:10:18 |
Message-ID: | CABh6Tc0Y1MBShF59FWQ-vivV5rb_dVJhtPrBoKyeB1w=fH-o6g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Esneiker Enriquez Cabrera | 2019-02-28 18:43:24 | RE: Duda |
Previous Message | Anthony Sotolongo | 2019-02-28 15:54:37 | Re: Duda |