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 <hmira...@gmail.com
<mailto: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 <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
