PgSQL replica lag trop important trafic write lourd
Commentaires
ouais classique. c quoi ton setup ? sync/async ? quelle version pg ? type de storage sur la replica ?
async replication. pg 14. storage ssd nvme sur primary. replica c'est du gp2 sur aws. je suspecte ça.
ah ouais gp2 ça peut être le bottleneck. gp2 c max 16k IOPS et 250MB/s pour 16TB. si t'as une petite taille de volume les IOPS sont nuls. tu peux burster mais c pas fait pour du sustained high write. pour une replica, tu lis bcp de WAL, ça bouffe des IOPS.
le volume fait 500gb. donc je suis à 1500 iops de base. le burst aide mais ça tient pas. je vois bien des périodes où le `iops_util` est à 100% sur la replica.
exactement. pour la replica t'as besoin de beaucoup d'IOPS en lecture pour appliquer les WAL. si tu peux pas écrire les WAL assez vite ça lag. passe en io1 ou io2 pour du high IOPS garanti, ou gp3 avec des IOPS provisionnés. c'est le plus direct.
ok c'est une option. j'avais aussi pensé à `max_wal_senders` et `wal_sender_timeout` sur le primary mais ça joue pas sur les IOPS de la replica. ni `wal_buffers`.
non ça c'est plus pour la connectivité/buffering côté primary. ce qui compte c'est la capacité de ta replica à ingérer et appliquer les WAL. si ton `pg_stat_replication` montre un `replay_lag` conséquent, c'est presque toujours le storage. ou alors un gros `long_running_query` sur la replica qui bloque l'application des WAL.
pas de requêtes longues sur la replica, je l'utilise juste pour du backup et monitoring. le `replay_lag` est le problème justement. c'est la métrique qui pète.
bon, si c'est pas un souci de network entre primary et replica, ni de CPU sur replica, et pas de requêtes qui bloquent, c'est quasi sûr le storage. si t'es sur RDS, t'as des options pour augmenter les IOPS du volume.
on est sur EC2, pas RDS. je dois le faire manuellement. donc gp3 avec IOPS provisionnés. ça me semble la meilleure voie.
totalement. calcule bien tes besoins en IOPS. regarde ton `wal_bytes` généré sur le primary et le débit moyen sur la replica pour le replay. ça te donnera une idée.
j'ai déjà mesuré avec Prometheus, on est à ~100MB/s de WAL en pic. ça demande bcp d'IOPS en fait.
100MB/s c'est pas négligeable. surtout si tu as des petites écritures. ça va générer pas mal d'IOPS. le gp3 avec 3000 IOPS peut suffire mais si tu peux plus c'est mieux. la conversion de gp2 à gp3 est assez transparente.
ok je vais pusher pour passer la replica sur du gp3 avec 5000 IOPS provisionnés. ça devrait suffire pour le début. on verra après.
clair. c'est la solution la plus simple et la plus efficace pour ton cas. bonne chance !
merci bcp pour l'analyse. c'était bien le stockage. gp3 avec des IOPS provisionnés a réglé le problème de lag quasi instantanément. thx encore !
Laisser une réponse
Vous devez être connecté pour poster un message !
Rejoindre la communauté
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
suzanne86
Membre depuis le 30/01/2025actif
salut la compagnie. ma replica pgsql galère à suivre la prod. le lag monte à plusieurs minutes en pic de write. primary tourne bien, replica aussi niveau CPU/RAM mais disque saturé sur la replica. je vois des `pg_wal/` qui grossissent plus vite que le système arrive à les appliquer. des idées ?