Project

General

Profile

Demande #5763

Analyse de IOWait sur l'ensemble de l'infra

Added by pitchum . 8 months ago. Updated about 1 month ago.

Status:
En cours de traitement
Priority:
Normale
Assignee:
-
Category:
-
Start date:
01/29/2022
Due date:
% Done:

0%

Estimated time:

Description

Depuis l'upgrade Bullseye de l'ensemble de l'infra en décembre, on constate de fréquentes alertes de LOAD sur certaines VM (valise notamment) et des alertes IOWAIT DRBD sur les hyperviseurs.

C'est probablement la cause des erreurs 502 signalées par LordPhoenix sur mastodon


Files

iowait_drbd_maine.png (112 KB) iowait_drbd_maine.png pitchum ., 02/09/2022 09:52 AM
iowait_drbd_coon.png (67.2 KB) iowait_drbd_coon.png pitchum ., 02/09/2022 09:52 AM
cpu_vms.png (132 KB) cpu_vms.png pitchum ., 02/09/2022 10:04 AM

History

#1

Updated by pitchum . 8 months ago

J'ai essayé de voir si on pouvait "optimiser" nos fichiers qcow2.
Sur coon, j'ai attaché 2 nouveaux disques à la VM ludo :
  • un disque qcow2 tout neuf :
    qemu-img create -f qcow2 -o preallocation=falloc,cluster_size=262144,lazy_refcounts=on,extended_l2=on /var/lib/libvirt/coon/ludo-bis.qcow2 20G
    virsh attach-disk ludo /var/lib/libvirt/coon/ludo-bis.qcow2 vdb --subdriver qcow2 --live --config
  • un disque LVM indépendant de DRBD
    lvcreate -n vm-ludo-test -L 20G vg_coon
    virsh attach-disk ludo /dev/vg_coon/vm-ludo-test vdc --subdriver raw --live --config

Sur ludo, j'ai utilisé chacun de ces nouveaux disques dans un PV dédié et créé un LV dédié, mountés (dans des dossier choisis un peu à l'arrache).
J'avais donc 3 dossiers dans lesquels j'allais pouvoir faire des tests d'écriture avec la commande dd, en suivant les suggestions fournies sur
cyberciti.biz/howto-linux-unix-test-disk-performance-with-dd-command :

  • /var => sur le qcow2 original
  • /mnt => sur le qcow2 tout neuf
  • /tmp/lvm_disk => sur la partition LVM sur coon

Résultats

disk throughput (write speed)

=(^-^)=root@ludo:~# dd if=/dev/zero of=/mnt/test-dd1.img bs=1G count=1 oflag=dsync
1+0 enregistrements lus
1+0 enregistrements écrits
1073741824 octets (1,1 GB, 1,0 GiB) copiés, 49,3794 s, 21,7 MB/s

=(^-^)=root@ludo:~# dd if=/dev/zero of=/var/test-dd1.img bs=1G count=1 oflag=dsync
1+0 enregistrements lus
1+0 enregistrements écrits
1073741824 octets (1,1 GB, 1,0 GiB) copiés, 50,9006 s, 21,1 MB/s

=(^-^)=root@ludo:~# dd if=/dev/zero of=/tmp/lvm_disk/test-dd1.img bs=1G count=1 oflag=dsync
1+0 enregistrements lus
1+0 enregistrements écrits
1073741824 octets (1,1 GB, 1,0 GiB) copiés, 45,3781 s, 23,7 MB/s

disk latency

=(^-^)=root@ludo:~# dd if=/dev/zero of=/var/test-dd2.img bs=512 count=1000 oflag=dsync
1000+0 enregistrements lus
1000+0 enregistrements écrits
512000 octets (512 kB, 500 KiB) copiés, 476,124 s, 1,1 kB/s

=(^-^)=root@ludo:~# dd if=/dev/zero of=/mnt/test-dd2.img bs=512 count=1000 oflag=dsync
1000+0 enregistrements lus
1000+0 enregistrements écrits
512000 octets (512 kB, 500 KiB) copiés, 411,88 s, 1,2 kB/s

=(^-^)=root@ludo:~# dd if=/dev/zero of=/tmp/lvm_disk/test-dd2.img bs=512 count=1000 oflag=dsync
1000+0 enregistrements lus
1000+0 enregistrements écrits
512000 octets (512 kB, 500 KiB) copiés, 241,711 s, 2,1 kB/s

conclusion

On dirait qu'avec LVM on gagne en latence.
Pas sûr que ça justifie de remettre en cause l'usage de DRBD.

Il y a sûrement d'autres tests à faire.

#2

Updated by Pierre-Louis Bonicoli 8 months ago

En ce qui concerne le temps de création de la sauvegarde du service Gitea avant sa mise à jour, voici ci-dessous quelques durées. Je n'ai pas l'impression que la mise à jour en Bullseye ait un impact sur la durée de la création de cette sauvegarde. La taille de la sauvegarde est actuellement de 4.9Go.

Actions Durée de la création de la sauvegarde du service Gitea Fin (approximative) de la mise à jour
mise à jour 1.14.6 5 minutes 08/08 23h18
mise à jour 1.15.3 8 minutes 25/09 15h42
doublement de la taille de la sauvegarde (en raison d'un nouveau gros dépôt)
mise à jour 1.15.6 12 minutes 30/10 12h49
migration bullseye
mise à jour 1.15.7 20 minutes 21/12 17h
mise à jour 1.15.8 13 minutes 24/12 00h24
mise à jour 1.15.9 26 minutes 31/12 01h30 => BACKUP!
mise à jour 1.15.10 12 minutes 20/01 02h38
mise à jour 1.15.11 10 minutes 03/02 00h34

La commande iotop sur les hyperviseurs indique t'elle quelque chose de particulier ? Quelle(s) VM génère(nt) les IO ? Il n'y a pas d'autres IO que celles liées à DRDB ?

#3

Updated by pitchum . 8 months ago

Les IO Wait DRBD de maine ont toujours été élevés, ceux de coon ont commencé à grimper en décembre.
(ne pas se fier à l'unité affichée sur les graphes, je n'ai pas trouvé comment la corriger)

Métrologie pour coon

Métrologie pour maine

Et concernant les VMs, nous n'avons de la métrologie CPU que depuis trop peu de temps pour pouvoir comparer avant/après.

Mais les taux d'iowait me paraissent quand même assez élevés, et ce en permanence, pas seulement pendant les backups.
En particulier sur valise qui tourne sur maine.

#4

Updated by Pierre-Louis Bonicoli 6 months ago

  • Target version changed from Sprint 2022 février to Sprint 2022 avril
#5

Updated by Chris Mann 6 months ago

conclusion

On dirait qu'avec LVM on gagne en latence.
Pas sûr que ça justifie de remettre en cause l'usage de DRBD.

Il y a sûrement d'autres tests à faire.

Pas tout à fait. Le test est sur un fichier. Je soupçonne le problème étant un nombre important de petits fichiers (dans un nombre de comptes). La nature du volume de data est une piste parmi d'autres à explorer.

#6

Updated by Pierre-Louis Bonicoli 5 months ago

  • Target version changed from Sprint 2022 avril to Sprint 2022 mai
#7

Updated by Pierre-Louis Bonicoli 4 months ago

  • Target version changed from Sprint 2022 mai to Sprint 2022 juin
#8

Updated by Pierre-Louis Bonicoli 3 months ago

  • Target version changed from Sprint 2022 juin to Sprint 2022 juillet-août
#9

Updated by Pierre-Louis Bonicoli about 1 month ago

  • Target version changed from Sprint 2022 juillet-août to Sprint 2022 septembre

Also available in: Atom PDF