15 commentaires
bienvenue au club des gens qui détestent le storage engine d'etcd tu as quoi comme système de fichiers sur tes partitions de données
regarde aussi ton scheduler d'io au niveau du kernel si tu es en mq-deadline ça peut créer des contentions inutiles sur du NVMe très rapide
on est sur du xfs avec les options de montage par défaut et pour le scheduler je suis déjà en none sur tous les nodes masters
cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadlineest ce que tu as vérifié si tes disques font du power management agressif le APST peut foutre la merde sur les temps de réponse quand le disque sort de veille
donne nous un iostat détaillé pendant un spike pour voir la queue depth et le await
voilà ce que je récupère quand ça sature c'est incompréhensible le await s'envole mais le disque n'est pas du tout chargé
Device r/s w/s rMB/s wMB/s r_await w_await aqu-sz %util
nvme0n1 0.00 450.00 0.00 12.50 0.00 480.00 1.2 5.00un w_await à 480ms avec seulement 450 w/s c'est une catastrophe ton kernel attend le disque pendant une éternité
c'est peut être pas le disque lui même mais le bus pcie qui sature ou des erreurs d'allocation mémoire au niveau du driver nvme regarde ton dmesg
j'ai fouillé dmesg et j'ai trouvé des trucs bizarres qui popent en même temps que les spikes
nvme nvme0: pci function 0000:01:00.0 failed to set APST
nvme nvme0: Switched to low power state failedvoilà on y est tes disques essaient de passer en mode économie d'énergie et le contrôleur freeze pendant la transition
faut désactiver ça direct au boot du kernel ajoute nvme_core.default_ps_max_latency_us=0 dans ta config grub
je viens de tester sur un node en préprod et effectivement les latences wal ont l'air de se stabiliser sous les 5ms
on va passer ça en prod cette nuit je croise les doigts pour que ça tienne la charge de demain matin
pense aussi à mettre ton processeur en performance mode avec cpupower sinon le scaling de fréquence peut aussi rajouter du jitter sur les syscalls fsync
et oublie pas de vérifier si le firmware de tes ssd est à jour certains constructeurs ont sorti des patchs spécifiques pour ce bug de transition d'état
ça marche je vais check les firmwares aussi merci pour le coup de main j'aurais jamais pensé que le power saving détruisait les performances d'etcd à ce point là
Laisser une réponse
Vous devez être connecté pour poster un message !
j'en peux plus d'etcd qui nous lâche le vendredi soir sans raison apparente on a des clusters kubernetes sur du bare metal avec des disques NVMe de compétition et pourtant on se tape des latences de fou sur les écritures wal
les métriques prometheus montrent des spikes à plus de 500ms sur etcd_disk_wal_fsync_duration_seconds_bucket alors que les disques sont quasiment idles en terme d'iops on a testé de changer les câbles et les switchs mais rien ne bouge