Cuando la BD vuelca de golpe al disco, de forma periódica, los cambios que tiene en memoria, las consultas se ralentizan.
Por qué Los cambios se acumulan y se escriben en disco periódicamente → Efecto En ese momento el disco está muy ocupado y las consultas se retrasan → En pantalla Guardados y cargas que se vuelven lentos periódicamente
Responsable principal Infraestructura de BD (Equipo de infraestructura)
Tareas (Equipo de infraestructura)
Repartir los checkpoints en partes pequeñas y uniformes, dimensionar con holgura el log de transacciones (redo log, WAL), usar discos rápidos.
En el gráfico
Picos periódicos · Latencia de las consultas a la BD, volumen de escritura en disco
Dónde mirar
En PostgreSQL, la hora de cada checkpoint y los búferes escritos en el log de log_checkpoints (activado por defecto en las versiones recientes), el número de checkpoints (num_timed y num_requested de pg_stat_checkpointer desde la versión 17; checkpoints_timed y checkpoints_req de pg_stat_bgwriter en la 16 y anteriores) y los avisos de checkpoint_warning. En MySQL, la diferencia entre Log sequence number y Last checkpoint at en la sección LOG de SHOW ENGINE INNODB STATUS. Superponer también el volumen y la latencia de escritura en disco del servidor
Se confirma si
Los picos de latencia de las consultas coinciden con la hora de los checkpoints, y en ese momento se disparan el volumen y la latencia de escritura en disco. En PostgreSQL, si hay muchos más checkpoints solicitados (num_requested) que checkpoints por tiempo (num_timed), el WAL llega a menudo a max_wal_size y los checkpoints se adelantan
Se descarta si
Si los picos siguen un ciclo sin relación con la hora de los checkpoints, apunta a copias de seguridad o procesos batch (dk-backup, db-batch)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Si el log de transacciones que guarda el registro de cambios (el redo log de MySQL, el WAL de PostgreSQL) es demasiado pequeño, cada vez que se llena la BD tiene que hacer un checkpoint de golpe y con prisa, y el throughput de escritura cae mucho durante unos instantes.
Fuentes
WAL Configuration (PostgreSQL Documentation)PostgreSQL Por defecto se hace un checkpoint cada 5 minutos o cada 1 GB de WAL (max_wal_size), y es costoso porque escribe todas las páginas sucias. checkpoint_completion_target reparte las escrituras para evitar avalanchas de E/S. Si el intervalo entre checkpoints es menor que checkpoint_warning, se escribe en el log un aviso para aumentar max_wal_size
Configuring Buffer Pool FlushingMySQL Cuando el redo log se llena, un checkpoint urgente (sharp) reduce el throughput durante un momento; el flushing adaptativo reparte las escrituras de forma uniforme
PostgreSQL 17 Release NotesPostgreSQL Nueva vista pg_stat_checkpointer, a la que pasan desde pg_stat_bgwriter las columnas relacionadas con los checkpoints