Optimización de rendimiento, ¿qué pasa con max_wal_size?

Instalación
1

Hola,

La última actualización de beta-3 a beta-4 fue más “engorrosa” de lo habitual para nosotros y algo como lo siguiente seguía apareciendo debido a los registros:
Consider increasing the configuration parameter "max_wal_size".

Dado que no soy un experto en este asunto, al buscar en Google se mostró que este parámetro max_wal_size puede ser muy importante para el rendimiento (solo superado por shared_buffers según algunos, ver abajo):
Tuning max_wal_size in PostgreSQL | EDB (enterprisedb.com)
Tuning Your Postgres Database for High Write Loads (crunchydata.com)
PostgreSQL Performance Tuning and Optimization Guide - Sematext

¿Alguna opinión sobre esto? ¿Debería cambiarse el parámetro max_wal_size, incluso si esto solo sucedió durante la actualización?

Como contexto, tenemos un foro grande con más de 7 millones de publicaciones, que consume muchos recursos, un par de veces por semana con 400-600 usuarios simultáneos actualizando, publicando y haciendo todo al mismo tiempo. No hay problemas con eso, :smiley:, pero a veces nos vemos obligados a optimizar y tratar de obtener el mejor rendimiento posible para nuestros recursos (finitos).

1 me gusta
2

¿Cuál es el valor de ejecutar SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter; contra la base de datos?

3

Veamos si lo entendí bien:

SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter; 
checkpoints_timed | checkpoints_req 
-------------------+-----------------
              4936 |             225
(1 row)
1 me gusta
4

Parece que fue causado principalmente por migraciones durante la actualización, y día a día el foro está bien.

Enviamos algunas migraciones pesadas este mes, ¿no tendrás por casualidad tu registro de reconstrucción?

2 Me gusta
5

No, puedo intentar encontrarlo más tarde, pero confío en tu criterio :+1: (el foro funciona bien aparte de algunos problemas de carga durante esas horas pico que mencioné).

1 me gusta