13 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.
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.
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 !
Salut à tous. Je commence à fatiguer sur un problème d'archivage des WAL sur notre cluster PostgreSQL (version 15) tournant sous EKS.
On utilise
wal-gpour 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'outilarchive_commandsort 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 ?