> On 16/02/2019, at 3:05 PM, Carlos T. Groero Carmona <cton...@gmail.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 <alvhe...@alvh.no-ip.org > <mailto:alvhe...@alvh.no-ip.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>
