Re: Urgente, postgres down

Creo que hay varios problemas aquí, podemos ver los más basicos.

Revisa que las llaves Foraneas tengan indices.
https://dba.stackexchange.com/questions/121976/discover-missing-foreign-keys-and-or-indexes

Dices que tienes tablas particionadas, esto solo sirve si las consultas
tienen en el Where el criterio de la particion, si son por fechas que
las consultas en la tabla gigantesca sean por fechas. de lo contrario no
te va a ayudar mucho.

Los parametros el S.O. los ajustaste para manejar una base de datos
grande ? Usas un Filesystem como XFS ? ( me gusta más que ext3 o ext4 )
pero es algo personal.

Sobre los IO. iostat -m -x /dev/sd? 3 ( que te dice, contención ? ).

sar ( que te dice sobre las contenciones ? ).

Los discos en la maquina real estan todos sanos ?

La fuente de poder estan las dos activas ? ( una fuente puesta en un
servidor pero desenchufada va a desabilitar los cache de las controladora.

Los cache estan funcionando ? ( supongo que tienes algo como HP o DELL,
o alguna marga que no sea un PC armado corriendo aquí ).

el shmmax esta reajustado de acuerdo al shared buffers ? ( no puedes
tener un shared buffer grande si no tienes el S.O. en sintonía con la
base de datos. ( elimina el Swap si puedes ), y no asignes más del 80% a
la base de datos si es lo unico que corre ahi ).

Sobre python ( lee sobre pool y postgresql ).

Si usas jdbc ( pasa el parametro
/-Djava.security.egd=file:/dev/./urandom )//
/http://ruleoftech.com/2016/avoiding-jvm-delays-caused-by-random-number-generation
).

Puede que no sea importante, pero /dev/random es super malo para muchas
conexiones sobre todo si no usas pooling con java.

Es super raro que la base template1 este tan fragmentada, algo debe
estar escribiendo y borrando cosas. revisa que tabla es, puede que sea
alguna de estadisticas.

On 11/02/2019 8:45 PM, Carlos T. Groero Carmona wrote:
> Hola Lista, disculpen la extension del correo, solo intento comentar
> mis experiencias positivas y negativas para que aprendan de mis
> errores o me sugieran/comenten lo que consideren.
>
> La version que estoy usando es 9.3.23. Cuando el servidor dejo de
> aceptar conectiones de escrutura para evitar el wraparound pudimos
> conectarnos en el mudo single-user, a la base de datos que decia en el
> error. Se le ejecuto un vacuum a esa base de datos y lo reiniciamos,
> pero todas las base de datos estaban asi, por lo que tuvimos que
> apagarlo nuevamente y ejecutar vacuum a todas las base de datos.
>
> En la ultima y mas grande, despues de 7 horas de vacuum en single-user
> decidimos detener el proceso de vacuum que estaba ejecutando, como
> estabamos en single-user decidimos unsar un Kill pid, el cual no
> funciono por lo que fuimos mas drasticos y usamos kill -9 pid,
> desgracuadamente esto nos cobro factura al tratar de levatar el
> servicio despues, pues se demoro alrededor de 30 min levantarlo. Asi
> que si exiate otra manera de detener este servicio cuandonse este
> ejecutando single-user seria genial.
>
> Despues que postgres finalmente volvio a estar en servicio, empece a
> revisar las tablar con mayor frozenxid y empece a ejecutar vacuum
> lograndolo bajar considerablemente (478 millones).
>
> Mi enfoque de trabajo estubo:
> 1. encontrar la base de datos con mayorr datfrozenxid usand;
> 2. buscar en esta base de datos las tablas con mayor relfrozenxid.
> 3. Ejecutar vacuum en esas tablas.
>
> Algo curioso salio en el proceso, y es que template0 es la "base de
> datos" con mayor datfrozenxid, me lleve una sorpres cuando trate de
> conectarme para ejecutar vacuum y no pude, pero en postgres.org
> <http://postgres.org> en el apartado de mensajes y respuestas encontre
> informacion diciendo que no te puedes conectar y que postgres o
> vheckea el datfrozenxid y que autovacuum se encargaria de todas formas
> por si acaso...en fin...la documentacion que he encontrado no me ha
> dejado claro como postgres trata esta BD y si puede representar un
> peligro nuevamente.
>
>
> Aproveche este suceso lamentable para cambiar algunos parametros en la
> configuracion de postgres que requerian reiniciar el servidor:
>
> hacer mas agresivo autovacuum
> autovacuum_max_workers: 6
> autovacuum_vacuum_cost_limit: 1500
> y enfoque autovacuum en tablas mas grande modificando scaler_factor y
> threshold..
>
> Tambien incremente
> shared_buffer a 32GB
> max_locks_per_transaction 1024
>
> Cuando pensaba que la tormenta habia pasado, recivimos una alerta de
> new relic con un aumento extremo en wl tiwmponde respuesta de la
> aplicacion por culpa del servidor de base de datos, disminui el
> cost_limit a 400, y recargue la configuracion y seguia aumentando el
> tiwmpo de respuesta. Chequeando pg_stat_activity me percado de que
> muchas queries estaban escribiendo aobre la misma tabla, revise por
> exclusived/dead locks y no habian, la unica solucion que encontre fue
> detener el autovacuum por 45 minutos hasta que el tiempo de respuesta
> se restableciera, apagandolo encontre unos deadlocks loa resolvi y
> tudo funciono como lo esperado, despues de 45 min volvi a encender el
> autovacuum y todo ha estado funcionando correctamente.
>
> Desgraciadamente aun mantengo el cost_limit a 400 no quiero aumentarlo
> y contribuir nuevamente a un cuello de botella de I/O que es lo que
> creo que sucedio.
>
> Sabemos que tenemos algunos problemas de arquitectura del software
> como se esta escribiendo en la base de datos, pero ahora mismo el
> codigo y la arquitectura no se va a tocar.
>
> Las medidas y metas propuestas a corto plazo son:
> 1.Migrar a 9.6 en un servidor muchooo mas potente que el actual con 5T
> SDS interno.
> 2.Recisar la configuracion de connection pool de Ruby/Rails y tratar
> de usarlo o optimizarlo pues esta por defecto.
> 3.Optimizar las consultas y tratar de usar algunas vistas
> materializadas donde sea oportuno.
> 4.Configurar el freeze setting the postgres
> 5.Eecutar vacuum siempre que sea posible en momentos de baja carga,
> hasta que logremos migrar y aumentar el numero de trabajadores de
> autovacuum y el cost_limit.
>
> Por cierto sobre vacuum hay algo extra que les quiero comentar,
> ejecutamos un vacuum analyze verbose a una de las base de datos y
> durante este momento un trabajo automatico se realizo, y postgres
> decia que no tenia suficiente shared memory despues que lw subi a 24GB
> el shared_buffer y a 4GB el maintenance_work_mem, el trabajo consitis
> en ejecutar unos ficheros para salvar informacion en la base de datos
> y se perdio informacion durante el proceso.
>
> es posible que:
> insertar trabajador 1 hay shared memory no hay problema.
> insertar trabajador 2, no hay shared memory pues no se inserta y se
> pasa al siguiente trabajador.
>
> insertando solo aquellos trabajadores de la lista cuando hubo shared
> memory, y si no habia se perdia esa informacion...?
>
> Ah, alguien me pregunto si usaba tablas particionadas y si, uso
> particionamiento por fecha y tambien por lista algo asi que cada
> cliente tiene su propia particion de la tabla tabla_x, y casualmente
> en esa tabla_x es donde mas operaciones de escritura se realizan.
>
> Saludos,
> Carlos.
>
>
>
>
>
>
>
>
>
>
>