PgSQL replica lag trop important trafic write lourd

Question

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 ?
SELECT \
    pg_wal_replay_pause_time(), \
    pg_last_wal_replay_lsn(), \
    pg_last_wal_receive_lsn(), \
    now() - pg_last_xact_replay_timestamp() AS replication_delay;

lopes-daniel · Answer

ouais classique. c quoi ton setup ? sync/async ? quelle version pg ? type de storage sur la replica ?

suzanne86 · Answer

async replication. pg 14. storage ssd nvme sur primary. replica c'est du gp2 sur aws. je suspecte ça.

lopes-daniel · Answer

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.

suzanne86 · Answer

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.

lopes-daniel · Answer

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.

suzanne86 · Answer

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.

lopes-daniel · Answer

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.

suzanne86 · Answer

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.

lopes-daniel · Answer

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.

suzanne86 · Answer

on est sur EC2, pas RDS. je dois le faire manuellement. donc gp3 avec IOPS provisionnés. ça me semble la meilleure voie.

lopes-daniel · Answer

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.

suzanne86 · Answer

j'ai déjà mesuré avec Prometheus, on est à ~100MB/s de WAL en pic. ça demande bcp d'IOPS en fait.

lopes-daniel · Answer

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.

suzanne86 · Answer

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.

lopes-daniel · Answer

clair. c'est la solution la plus simple et la plus efficace pour ton cas. bonne chance !

suzanne86 · Answer

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 !

PgSQL replica lag trop important trafic write lourd

16 commentaires

Laisser une réponse

Les Interfaces dans le langage de programmation Go

Les bases fondamentales de l'affichage graphique en SDL2

Découverte et installation de Docker

Pourquoi et comment créer des branches sur GitLab

WebAssembly au-delà du navigateur : Redéfinir l'Edge Computing et le Cloud Natif

Rejoindre la communauté