Backlog massif de WAL PostgreSQL sur EKS avec saturation S3
Commentaires
Bienvenue en enfer. C'est classique avec S3 quand on commence à avoir des débits élevés sur un seul prefix.
Est-ce que tu as vérifié si tu ne te prends pas un throttling de la part d'AWS ? Regarde tes metrics CloudWatch pour le bucket, spécifiquement les erreurs 503.
J'ai checké CloudWatch. Effectivement, j'ai des pics de `SlowDown` assez violents qui coïncident avec nos batchs d'écriture.
Le truc c'est que `wal-g` est censé gérer le retry. Voici ma commande actuelle :
archive_command = 'wal-g wal-push %p'Si S3 me jette, le kernel devrait juste voir un exit code non-zéro et Postgres retentera, mais là ça s'accumule beaucoup trop vite.
Le problème c'est que PostgreSQL attend que le shell se termine pour libérer le slot d'archivage. Si ton `wal-g` met 30 secondes à timeout sur S3, tu ne peux plus dépiler les WAL suivants assez vite.
Tu devrais wrapper ton appel dans un script pour loguer le stderr. Essaie de voir si ce n'est pas un souci de résolution DNS dans ton VPC qui ralentit chaque appel.
J'ai wrappé le bousin. Les logs crachent ça en boucle :
upload failed: x509: certificate signed by unknown authority
wal-g push failed: context deadline exceededAttends, pourquoi j'ai une erreur TLS x509 tout d'un coup ? On utilise des endpoints S3 via PrivateLink.
Ça, c'est typique d'une saturation de l'entropie ou d'un souci de ressources sur le noeud. Si ton CPU est à 100% à cause de l'ingestion, le handshake TLS peut foirer et sortir des erreurs bizarres.
Vérifie tes limites de ressources sur le pod PostgreSQL. Si tu es throttlé par le scheduler CPU du kernel, ton binaire Go n'aura pas assez de temps processeur pour finir le handshake TLS avant le timeout de S3.
Bien vu. J'ai regardé les stats cgroup du pod. On est au taquet sur les quotas CPU pendant les batchs. J'ai l'impression que le kernel Linux met le processus en pause pile pendant les appels système réseau.
Mais pourquoi l'erreur TLS x509 ?
En Go, quand le timeout arrive pile pendant la lecture des certs du root CA sur le disque, l'erreur retournée est parfois trompeuse. C'est souvent un effet de bord du throttling CPU.
Augmente tes `cpu limits` ou passe carrément en `Guaranteed` QoS class pour voir si le taux d'archivage remonte.
J'ai passé le pod en QoS Guaranteed et j'ai doublé la RAM au passage. Le débit d'archivage a un peu grimpé mais je n'arrive toujours pas à rattraper le retard. J'ai 4000 fichiers WAL en attente dans `pg_wal`.
J'ai testé un `ping` vers l'endpoint S3 depuis le pod, la latence est stable à 1ms.
Cherche pas, c'est le nombre de connexions TCP. Postgres lance un shell pour chaque fichier. C'est hyper inefficace car tu refais un handshake TLS complet à chaque fois.
Installe un bouncer de WAL ou utilise `archive_library` si tu es en Postgres 15+, ça évite le fork/exec systématique.
Je ne peux pas changer la config du serveur là maintenant sans reboot. J'ai essayé de paralléliser via un script custom qui utilise des workers en background.
Le souci persiste. Je viens de voir un truc dans `dmesg` sur le worker node :
nf_conntrack: table full, dropping packet
net_ratelimit: 456 callbacks suppressedC'est la table conntrack du kernel qui explose !
Ah ! Voilà ton coupable. Chaque tentative d'upload de WAL crée une nouvelle entrée dans conntrack. Avec tes retries et tes échecs, tu as saturé la table.
Vérifie la limite avec `sysctl net.netfilter.nf_conntrack_max`. Sur EKS, selon la taille de l'instance, c'est parfois très bas.
Effectivement, c'était setté à 262144. Je l'ai bumpé à 1048576 à chaud.
sysctl -w net.netfilter.nf_conntrack_max=1048576Les erreurs `SlowDown` ont disparu instantanément et le backlog de WAL est en train de fondre. Le kernel ne drop plus les paquets de retour de S3.
Top. Oublie pas de fixer ça dans ton template Terraform ou ton user-data pour que ça survive au prochain recyclage de nodes. Les limites par défaut sur les petites instances EC2 sont une plaie pour les DBs.
C'est noté. Je vais aussi passer sur une config avec un daemon de transfert persistant pour éviter de polluer conntrack avec des milliers de sockets éphémères. Merci pour le coup de main, je vais enfin pouvoir dormir un peu.
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
charlotte48
Membre depuis le 15/01/2025Salut à tous. Je commence à fatiguer sur un problème d'archivage des WAL sur notre cluster PostgreSQL (version 15) tournant sous EKS.
On utilise `wal-g` pour pousser les segments vers S3. Hier soir, sans raison apparente, le volume de données non archivées a explosé. On a rempli notre disque EBS dédié aux WAL en 2 heures. L'outil `archive_command` sort en erreur 1 sans message explicite dans les logs du pod PostgreSQL.
Le plus bizarre c'est que ça arrive uniquement sur l'instance primaire après une grosse phase d'ingestion. Quelqu'un a déjà eu ce genre de bottleneck ?