17 commentaires
salut check tes métriques disk i/o sur le serveur etcd même si tu penses que c'est ok. regarde le wal_fsync_duration_seconds et backend_commit_duration_seconds dans prometheus. des fois c'est pas le througput mais la latence
oui carrément la latence est critique pour etcd. tu es sur quel type de stockage ? hdd ssd nvme ? et le réseau entre tes membres etcd est clean ? pas de pertes de paquets ?
on est sur du ssd gp2 sur aws. le réseau est ok entre les membres ping est <1ms. le wal_fsync_duration_seconds est souvent au-dessus de 50ms et des pics à 200ms. backend_commit_duration_seconds suit le même pattern. ça sent le disque non ?
clairement ça sent le disque. gp2 c'est bien mais si t'as beaucoup d'iops et que t'es pas provisionné assez ou que ton burst credit est mort ça va ramer sec. as-tu regardé les métriques d'iops et de débit de ton volume ebs ?
oui et check aussi le snapshot-count et auto-compaction-retention de ta config etcd. un snapshot trop fréquent ou une compaction mal tunée ça peut impacter le i/o
les iops ebs sont dans les choux quand ça arrive genre on tape le max provisionné. snapshot-count est à 10000 par défaut. auto-compaction à 1h en revision mode. ptete réduire snapshot-count ?
10000 c'est pas mal en vrai. j'augmenterais plutôt les iops du volume ebs direct ou passer sur du gp3 en provisionnant bien. ou même io2 block express si le budget le permet. gp2 si t'es hors burst c'est la mort
avant d'aller sur io_uring je pense qu'un simple upgrade de volume ebs ou des instances avec du local nvme serait plus simple et efficace. on parle de etcd, la stabilité c'est primordial
totalement d'acc avec user 2. la solution la plus simple c'est souvent la meilleure pour ce genre de truc. un etcdctl check perf peut aussi t'aider à confirmer que le bottleneck c'est bien le disk i/o
ok je vais tester etcdctl check perf. pour le moment on a up le volume gp2 à 3000 iops et ça a un peu amélioré les choses mais c'est pas parfait. les pics sont moins hauts mais toujours là
si les pics sont toujours là même après avoir augmenté les iops ça peut venir d'autres choses. regarde les logs pour des leader election timeout ou des network partition warnings
non pas de warnings de leader election. les membres etcd se parlent bien. etcdctl check perf confirme que le write throughput est limité par le disk sync duration.
les instance types comme i3/i3en/m5d avec du nvme local c'est le top pour etcd. la latence est imbattable. juste gère bien tes volumes etcd avec un data-dir sur le nvme et member-remove si une instance meurt
on vient de migrer sur des instances i3 avec nvme local. les métriques wal_fsync_duration_seconds sont tombées en dessous de 1ms quasi tout le temps. l'api server est stable maintenant.
franchement passer sur du nvme local a tout changé. plus un seul warning de slow apply. thx à tous pour les tips !
Laisser une réponse
Vous devez être connecté pour poster un message !
yo la team ! on a un cluster k8s et l'api server fait la gueule des fois les writes sur etcd sont super lents on voit des warnings de timeout dans les logs d'etcd genre 5s pour un commit c'est pas normal pour notre infra. le disk i/o du node est ok pourtant. qqn a déjà vu ça ?