Re: Urgente, postgres down

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