Re: Urgente, postgres down

From: Francisco Olarte <folarte(at)peoplecall(dot)com>
To: "Carlos T(dot) Groero Carmona" <ctonetg(at)gmail(dot)com>
Cc: Lista PostgreSql <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Urgente, postgres down
Date: 2019-02-07 18:47:56
Message-ID: CA+bJJbycqWaJvAgXu4YMx0dEqQUgoiYyzhAh0=2+1Wm+bZ9Ldg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Carlos:

On Thu, Feb 7, 2019 at 5:40 PM Carlos T. Groero Carmona
<ctonetg(at)gmail(dot)com> wrote:
> Fransisco, gracias por tu comentario.
De nada hombre, a mandar.

> Despues que detuvimos el servidor apagado ejecutamos un vacuum en la base de datos que tenia datfrozenxid por encima de los 2 billones...actualmente tiene 1.92 billones
> Todas las tablas tienen relfrozenxid por debajo de mil millones

¿ Pero lo hicisteis en single user al final ?

> Autovacuum estuvo trabajando sin problema pero estaba usando configuraciones erroreas que lo hacian lento para una base de datos que ejecuta miles de writing transaction sin utilizar un connection pool,

Supongo que los miles de trans son por segundo, las infames TPS. Aun
si, el connection pool no creo que te vaya a ayudar salvo que sean las
apps las que "transaccionan" erroneamente y las agrupes en el pool (
IMO, si sin connection pool eres capaz de mandar X, con connection
pool mandaras aun mas ).

> en un momento estuve revisando el numero de dead_tup mientras autovacuum estaba trabajando en esa tabla y el numero en vez de disminuir estaba aumentando. La base de datos tine 880 tablas + otras base de datos (pequenas) y las tablas de postgres.

Desde luego eso no ayuda. Pero vamos, sin saber mucho mas del
problema, que no procede, poco te puedo recomendar, y aun asi no soy
un experto en tuneado de vacuums. Los parametros, no se que tal estan
( solos no dicen nada, sin saber el contexto, pero supongo que te los
habras currao ). Eso si no veo nada de los parametros que se usan para
el freeze, igual tienes que tunear alguno de esos tambien, o mandar a
mano "vacuum freeze" en los valles de actividad para que te aguante
bien. Pero vamos, me temo que tu problema necesita una solucion
holistica, analizar porque tienes tantas transacciones, mirar si
puedes colapsar las transacciones de escritura ( que teniendo muchas
imagino que lo habras hecho, porque es una de las cosas que aumenta
normalmetn el throughput ), mirar que tablas son las mas criticas y
meterles vaccum agresivo ( o intentar particionarlas ).

... snip, snip....

> En estos momentos estoy preocupando porque siento que viene otro shutdown pronto porque datfrozenxid se esta acercando cada vez mas a los 2billones.
> Ah el servidor esta corriendo actualmente solo que esta ejecutando toda la cache de las casi 8 horas que estuvo fuera de servicio...

Una cosa, el datfrozen es de la BD entera, pero no se como lo haces
para llevarlo tan rapido al limite, igual no hiciste vaccum completo?
Por otro lado, creo recordar que podias tener problemas si mezclabas
tablas muy poco actualizadas con tablas muy actualizadas ( las poco
actualizadas acumulan tuplas muy viejas y el autovacuum no entra
porque se tocan poco ), de la misma forma que te da problemas cuando
tienes una transaccion tonta muy larga y un monton de rapidas
mezcladas. Igual tienes que mirar de tunear los parametros POR TABLA
del autovacuum.

Pos na, que te vaya bien, ya nos contaras.

Francisco Olarte.

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Horacio Miranda 2019-02-07 23:02:39 Re: Consulta sobre archivo history del wal
Previous Message Stephen Amell 2019-02-07 18:12:32 Consulta sobre archivo history del wal