Re: Archivado particularmente voluminoso.

Alvaro,
Hola. Muchas gracias por tus comentarios.
Super claro respecto al primero y al segundo.

El siguiente en particular:
"Acá se reciclaron 3 segmentos de WAL, que son 48 MB; en todos tus
checkpoints parece ser la misma cantidad. No me parece un número
gigante la verdad ... digamos que es bastante modesto. Prueba a hacer
"pg_waldump -z" para mostrar un resumen por tipo de resource manager y
full-page writes del tráfico de WAL. Si los FPW (o FPI) son mayoría,
entonces hacer menos checkpoints debido a cambiar el timeout podría
disminuir mucho el tráfico total de WAL también."

Te consulto si podrías comentarme recomendarme algún link con info respecto
a la interpretación de la salida de ese comando.
Lo ejecuto respecto a un archivo de WAL en particular (uno cualquiera) pero
no logro interpretar el cuadro resultante.

Saludos y gracias nuevamente.
Federico.

El jue, 6 jun 2024 a las 14:33, Alvaro Herrera (<alvherre(at)alvh(dot)no-ip(dot)org>)
escribió:

> Hola
>
> Federico Pascual escribió:
>
> > Tenemos una db que está generando una gran cantidad de archivado. Esto es
> > que el archivado para un día en particular es muy voluminoso en
> comparación
> > con lo que ocupa la db.
>
> > En los logs tenemos por ejemplo la siguiente info:
> >
> > 2024-05-27 22:06:17.353 -03 [2302] LOG: empezando checkpoint: time
> > 2024-05-27 22:11:17.128 -03 [2302] LOG: empezando checkpoint: time
> > 2024-05-27 22:16:17.078 -03 [2302] LOG: empezando checkpoint: time
>
> Esto evidencia que tienes checkpoint_timeout=5min, que es el valor por
> omisión. Quizás podrías cambiarlo a 20min o algo así, lo cual podría
> disminuir la cantidad de WAL que se escribe y por lo tanto que se
> archiva.
>
> > 2024-05-27 22:20:46.803 -03 [2302] LOG: checkpoint completado: se
> escribió
> > 2690 buffers (0.8%); 0 archivo(s) WAL añadido(s), 0 eliminado(s), 3
> > reciclado(s); escritura=269.697 s, sincronización=0.005 s, total=269.726
> s;
> > archivos sincronizados=213, más largo=0.004 s, promedio=0.001 s;
> > distancia=46373 kB, estimado=50915 kB
>
> Acá se reciclaron 3 segmentos de WAL, que son 48 MB; en todos tus
> checkpoints parece ser la misma cantidad. No me parece un número
> gigante la verdad ... digamos que es bastante modesto. Prueba a hacer
> "pg_waldump -z" para mostrar un resumen por tipo de resource manager y
> full-page writes del tráfico de WAL. Si los FPW (o FPI) son mayoría,
> entonces hacer menos checkpoints debido a cambiar el timeout podría
> disminuir mucho el tráfico total de WAL también.
>
> --
> Álvaro Herrera PostgreSQL Developer —
> https://www.EnterpriseDB.com/
>