Re: Urgente, postgres down

Horacio, hay algo con lo que pueda ayudar para seguir mas de serca el
comportamiento de esta situacion especificamente en mi base de datos?

Aprovecho para comentarle que hoy tuve que detener nuevamente mi autovacuum
deamon, al rededor de las 8 empezaron a ver ciertos picos en New Relic en
el tiempo de respuesta del sistema, alrededor de las 9am fue constante y el
sistema no se recuperaba asi que tuve que deter el autovacuum por unas 4
horas y despues lo volvi a poner, paso lo mismo el sabado pasado.

Adjunto algunas imagenes de NewRelic y el resultado de sar en ese horario...
CPU %user %nice %system
%iowait %steal
%idle

08:20:01 AM all 55.99 0.00 24.23 2.63 0.00
17.15

08:30:01 AM all 54.52 0.00 23.45 3.03 0.00
19.00

08:40:01 AM all 53.41 0.00 23.18 2.91 0.00
20.51

08:50:01 AM all 49.47 0.00 22.11 3.28 0.00
25.14

09:00:01 AM all 51.37 0.00 23.93 2.76 0.00
21.93

09:10:01 AM all 54.62 0.00 23.47 3.11 0.00
18.80

09:20:01 AM all 59.90 0.00 24.90 2.22 0.00
12.98

09:30:01 AM all 56.02 0.00 24.09 2.87 0.00
17.02

09:40:01 AM all 51.98 0.00 22.74 3.22 0.00
22.06

09:50:01 AM all 46.69 0.00 20.66 3.03 0.00
29.62

10:00:01 AM all 46.02 0.00 20.51 2.79 0.00
30.69

Sobre el vacuumdb -F -a le comento que antes de ejecutarlo modifique
pg_database para que template0 aceptara coneciones que se realizo el vacuum
en todas las base de datos incluyendo template0.

en el entorno de pre-produccion no fui tan agresivo, solo me conecte a
template0 y realice un vacuum freeze analyze verbose; y se realizo
satisfacotoriamente, no puso el XID en cero, pero si lo llevo a un valor
casi cero.

Asi es como tengo pensado ejecutarlo en produccion porque la base de datos
es de 2TB y he autovacuum no ha podido realizar su trabajo correctamente
por lo que hay mucho trabajo que realizar ahi por vacuum asi que solo voy a
realizar vacuum freeze analyze verborse; en todas las base de datos menos
en la de produccion.

El XID de mi base de datos principal crece cada 30min aproximadamente en
1.7millones, tengo un cron job ejecutando la consulta y guardandolo en un
log. El crecimiento diario de mi base de datos es de aproximadamente 5GB
diarios, aunque al final del mes eliminamos las tablas particionadas por
meses que han estado salvadas por mas de 13 meses, recuperando alrededor de
40GB, entonces mi base de datos crece aproximadamente en 110GB al mes,
ah...solo manejamos texto.

Actualmente solo uso pgBadger para analyzar los logs y me encuentro en la
face inicial de instalar los plugings de NewRelic para monitoriar las base
de datos, aunque eso sera un procesolargo, ues primero sera probado en 3 o
4 servidores diferentes antes de llegar a produccion.

Digame si hay algo mas que quiera saber o quiera probar para llegar a un
entorno mas sercano sobre lo que esta sucediendo.

On Fri, Feb 15, 2019 at 4:12 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:

> On 2019-Feb-16, Horacio Miranda wrote:
>
> > Creo que es cosa de ejecutar la consulta:
> > SELECT
> > datname,
> > max(age(datfrozenxid)),
> > round(max(age(datfrozenxid)) / 2100000000.0 * 100.0, 3) AS
> percentage_transaction_ids_used
> > FROM pg_database
> > -- where datallowconn = true
> > group by datname
> > order by 2 desc;
> >
> > y Luego el vacuumdb -F -a ( -F es freeze y -a en todas las bases de
> datos ), el template0 no debe liberarse y las demás en mi caso el valor no
> cambio ) solo cuando abro el template0 es que el numero se va a cero.
>
> No recomiendo esto en una instancia con 7 TB de datos en total. Es
> mejor dejar que autovacuum haga su trabajo.
>
> --
> Álvaro Herrera Niebla, Chile
>