Re: Urgente, postgres down

> On 16/02/2019, at 3:05 PM, Carlos T. Groero Carmona <ctonetg(at)gmail(dot)com> wrote:
>
> Horacio, hay algo con lo que pueda ayudar para seguir mas de serca el comportamiento de esta situacion especificamente en mi base de datos?

Si realmente quieres saber que esta pasando, vas a tener que usar pgreply en tu ambiente de pruebas e investigar que esta ocurriendo.

Mis comentarios entre lineas.

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

Puede que tengas que ajustar algunos parametros del autovacuum solamente, lee sobre los parametros y cambia la frecuencia de vacuum ( o pega los settings que tienes sobre autovacuum. ).

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

Esto es cada 10 min ( es un promedio ) si quieres saber que pasa en cada minuto modifica el sar la frecuencia de snapshoots.

> 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

Mirando el gráfico de respuestas miraría dos cosas.
1.0 capturar las consultas que se demoran más de 1 segundo.
2.0 Generar un P2 a los desarrolladores para que paren lo que están haciendo y hagan que el código funciones con un pool de conecciones. Al crear una nueva conexion lo que haces es generar un nuevo contexto, en Linux esto se evita a toda costa sobre todo en sistemas de alto trafico.

Ahora esta es la lógica en bases de datos. los indices te ayudar a evitar full scan, pero el uso de indices usa más CPU, revisa cual es tu contención CPU o disco ?

PS: Algo que reviso siempre ( dmesg ) mensajes del kernel, algunas veces el Linux esta pidiendo ayuda /var/log/messages pero esta ayuda se puede detectar con dmesg también.
Ps2: Trafico de red, si tienes mucho trafico en la red, revisa si tienes el DMI de la tarjeta de red ( el driver ) bien configurado, si los mtu son 1500 o jumbo frames (9000) y sobre todo es un gran no no, si tienes los servidores trabajando a 10Gb y firewall entre medio a 1Gb links ( esto es un problema con Linux 6 y 7 para payloads sobre 2.4MB ).

Más allá de revisar otros puntos creo que aquí esta tu 80/20 ( revisar que punto es el que te esta generando el 80 % de los problemas para atacarlo ).

> On Fri, Feb 15, 2019 at 4:12 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org <mailto: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
> <Screen Shot 2019-02-15 at 9.30.36 AM.png>