latence disque folle sur un serveur linux spécifique

Question

Salut la tech ! J'ai un serveur de base de données (PostgreSQL) qui se plaint de latences I/O monstrueuses, genre plusieurs centaines de ms pour des écritures qui devraient être en ms. J'ai checké le disque physique, pas d'erreurs SMART, RAID ok. iostat me montre des %util élevé (90%+) mais des w/s et r/s pas délirants (quelques centaines). Le CPU est pas saturé. C'est comme si le disque est occupé à rien faire. Des idées pour creuser ?
# iostat -x 1
device            r/s     w/s     rkb/s     wkb/s   rrqm/s   wrqm/s  %rrqm  %wrqm aqu-sz await  svctm  %util
sdb             20.00  100.00    256.00   1280.00     0.00     0.00   0.00   0.00  50.00 450.00 8.00  96.00

david-jacob · Answer

Salut. Si

await

est haut et

svctm

bas, ça sent le file system ou le scheduler I/O. T'as quoi comme FS et quel scheduler est actif sur

sdb

?

cat /sys/block/sdb/queue/scheduler

pour voir. Et la taille des queues du FS genre

io_setup

ou

nr_requests

si c'est du blk-mq

diaz-philippe · Answer

Et regarde aussi le nombre d'inodes libres sur tes FS. Un manque d'inodes peut causer des latences bizarres pour les écritures de petits fichiers ou des créations/suppressions fréquentes. Ça impacte le temps que le système met à trouver un bloc libre

foucher-amelie · Answer

ok pour le scheduler c'est

mq-deadline

(par défaut je crois), et le FS c'est du

ext4

. Inodes libres j'ai check c'est ok. Pour les queues, je suis en blk-mq, la queue

nr_requests

est à 256. Ça me semble pas déconnant. Mais le fait que

await

soit 450ms et

svctm

8ms c'est vraiment chelou

david-jacob · Answer

Le

await

est le temps d'attente moyen des requêtes incluant le temps en queue,

svctm

c'est le temps de service réel du device. Un gros écart comme ça indique que les requêtes attendent beaucoup dans la queue I/O avant d'être traitées. Le

aqu-sz

(average queue size) à 50 confirme ça. Essaye de passer le scheduler en

none

si tu utilises un RAID hardware ou si t'es sur du NVMe ultra rapide, des fois le scheduler fait plus de mal que de bien

renaud-maggie · Answer

Si t'es sur une VM, la couche de virtualisation peut aussi introduire des soucis. T'es sur quel hyperviseur ? Et quel type de disque virtuel ? Virtio-blk ? Virtio-scsi ? Si c'est virtio-blk,

mq-deadline

est pas toujours le meilleur,

none

ou

noop

peuvent être mieux. et check les métriques i/o au niveau de l'hyperviseur pour voir si le problème vient pas de là

foucher-amelie · Answer

C'est une VM oui, sur Proxmox avec des disques VirtIO. Je vais tenter de passer le scheduler à

none

pour voir si ça change quelque chose. On a pas de métriques hyperviseur pour l'instant je vais voir pour en mettre en place. Je redémarre le service postgreSQL pour appliquer le changement et je vous dis

diaz-philippe · Answer

ouais sur virtio none est souvent le meilleur choix car le scheduler est déjà géré par l'hyperviseur ou le storage backend. Double scheduler ça fait double peine

david-jacob · Answer

Exactement. Et vérifie aussi l'alignement des partitions du FS par rapport aux blocs du disque physique et du RAID. Des misalignements peuvent pénaliser les performances I/O, surtout pour les écritures

foucher-amelie · Answer

MILLE MERCIS !! Le passage à

none

sur le scheduler a fait chuter l'await à des valeurs normales (genre 2-3ms). Le serveur respire enfin et PostgreSQL est content. C'était bien ce foutu double scheduling qui foutait la merde. Content de l'avoir trouvé !

latence disque folle sur un serveur linux spécifique

Commentaires

Laisser une réponse

Faciliter le déploiements k8s avec Kustomize

Conclusion du cours sur le DevOps

Comprendre et utiliser Filebeat dans la stack ELK

Rejoindre la communauté