La création d'instantanés LXD ZFS ralentit à mesure qu'augmente le nombre d'instantanés
Ubuntu 18.04 LTS - LXD Ubuntu est lancé à l'aide de ZFS en boucle (environ 400 Mo)
# lxc launch ubuntu:16.04 test -s ianzfspool
(J'ai un autre conteneur multi-Go inactif utilisant le même ianzfspool.) J'ai beaucoup d'espace dans le pool:
# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
ianzfspool 99.5G 13.7G 85.8G - 2% 13% 1.00x ONLINE -
Si je boucle, en utilisant lxc pour créer des instantanés du conteneur de test inactif (400 Mo), les premiers sont créés en quelques secondes. À mesure que le nombre d'instantanés lxc augmente (plus de 1 200 actuellement), leur création prend maintenant quelques minutes. J'ai un script en cours d'exécution dans le conteneur de test qui place la date du jour dans un fichier dans/tmp toutes les quelques secondes, donc j'ai un fichier qui change dans le conteneur à chaque instantané; sinon, le conteneur est principalement inactif. Les premiers instantanés lxc utilisaient environ 25 Ko; les actuels (après 1 200 instantanés) utilisent 66K. (Après 2 470 instantanés, ils utilisent chacun 115K et après 7 500 instantanés, ils utilisent chacun 293K.)
#!/bin/sh -u
# Create snapshots of the Ubuntu test container.
count=0
while : ; do
count=$(( count + 1 ))
cp=$( printf "%05d" $count )
lxc snapshot test snap$cp
echo "$0: done $cp" >/tmp/icount.txt
done
Edit 1: Je suis actuellement à environ 2 470 lxc snapshots et chaque nouvel instantané prend environ quatre minutes à créer et utilise environ 115K. Si j'appelle zfs snapshot pour prendre directement un instantané du conteneur, au lieu d'utiliser lxc snapshot, l'instantané prend moins d'une seconde, même avec 2 470 instantanés existants. L'instantané direct zfs utilise uniquement 20K (au lieu de 115K). Lancer zfs list ne prend qu'une seconde ou deux. Si je lance lxc list (au lieu de zfs list), cela prend actuellement plus de quatre minutes avec 2 470 instantanés existants. Donc, la création d’instantané et le ralentissement de la liste ne se font pas avec ZFS, mais avec LXD. En effet, le processus lxd a utilisé lui-même 4 253 secondes de processeur et a jusqu’à présent un VSIZE de 3,9G dans cette expérience de création d’instantané.
J'ai mis en pause le script de création de capture instantanée lxc et en ai écrit une pour créer en boucle des captures instantanées directes zfs et il a créé plus de captures instantanées en cinq minutes que lxc en trois jours. Je l'ai suspendu après environ 3 000 instantanés ZFS directs.
Je viens de relancer lxc list et, bien sûr, il ne montre toujours que les 2 471 images instantanées lxc, mais il ne s’exécute plus que dans 40 secondes au lieu de quatre. Je viens de créer un autre lxc snapshot et cela n'a pris que 49 secondes au lieu de quatre minutes. Qu'est ce qui a changé? La création d’un ensemble d’instantanés zfs directs a-t-elle accéléré en quelque sorte accélérer la création et le listage de lxc? Les instantanés lxc sont toujours beaucoup plus lents à créer que les instantanés directs zfs, mais quelque chose s’est amélioré avec la création d’un instantané lxc (de quatre minutes à 49 secondes).
Je laisse la création d'instantanés ZFS se poursuivre jusqu'à ce que 10 000 instantanés ZFS directs soient créés. (J'ai maintenant 2 472 instantanés lxc et 10 000 instantanés zfs directs de ce conteneur de test.) Le lxc list prend maintenant 90 secondes (au lieu de 40) et lxc snapshot prend 100 secondes (au lieu de 49). L'utilisation directe de ZFS est toujours deux ordres de grandeur plus rapide que via LXD.
Edit 2: Après un redémarrage, la création d'instantanés LXD s'est accélérée. Je suis à 7 470 instantanés créés via ma boucle lxc snapshot et chaque instantané prend maintenant environ 30 secondes pour créer et a une taille de 293K. Le lxc list prend 45 secondes. Le zfs list prend 105 secondes et génère 17 507 lignes de sortie (qui comprend les 10 000 instantanés ZFS directs). Faire zfs snapshot ianzfspool/containers/test@iansnap10001 directement (pas via LXD) prend moins d’une demi-seconde - encore beaucoup plus rapidement que via LXD.
Où puis-je trouver de la documentation sur les raisons pour lesquelles la création d'instantanés LXD ralentit et sur les moyens d'accélérer les choses? (Si les instantanés LXD avec ZFS étaient aussi bon marché que prévu, j'espérais exécuter des instantanés toutes les 5 minutes et les conserver pendant environ une semaine, ce qui représenterait 2 016 instantanés. J'ai lu que les instantanés LVM sont un inconvénient pour la performance. , mais rien de ce que j'ai lu n’ait dit la même chose à propos de LXD avec ZFS. Je vois que je pourrais contourner LXD et utiliser des instantanés ZFS, mais pourquoi dois-je le faire? LXD est-il réparable?)
Le processus lxd sur l'hôte utilise beaucoup de processeurs et grossit (ceci après 1200 instantanés):
PID VSTACK VSIZE RSIZE PSIZE VGROW RGROW SWAPSZ MEM CMD 1/8
10663 132K 3.7G 1.1G 0K 0K 0K 2580K 14% lxd
Je n’ai pas d’expérience avec lxd snapshot. Le mieux que je puisse faire est donc de deviner son implémentation et de vous donner plus de détails sur les instantanés ZFS.
Les instantanés ZFS sont conçus de manière à ne pas alourdir les lectures et les écritures en cours. (Comme vous l'avez mentionné, les instantanés LVM ajoutent une pénalité de performances, sous la forme d'une amplification d'écriture.) Pour ce faire, ZFS a une opération interne appelée txg_sync qui ressemble à une écriture par lots de toutes les entrées-sorties asynchrones récentes. cela se produit automatiquement toutes les 10 secondes, ainsi que chaque fois que la structure du système de fichiers change (par exemple, lorsque vous prenez un instantané). Cela provoque un tas d’IO, ce qui peut théoriquement ralentir les écritures synchrones simultanées en raison d’un encombrement (bien que les écritures de synchronisation aient la priorité). Cependant, il semble que vous n’ayez presque rien écrit dans votre système de fichiers (et probablement pas beaucoup plus dans le reste du pool).
À mon avis, ce sont en fait les lectures de métadonnées qui deviennent lentes. En théorie, lxd snapshot pourrait simplement prendre un instantané ZFS et continuer, ce qui devrait prendre un laps de temps constant (en supposant que IO charge). Cependant, je suppose qu’il essaie également de répertorier tous les instantanés au cours de cette opération (équivalent à zfs list), ce qui implique de lire un tas de métadonnées pour chaque instantané, qui est souvent réparti dans le pool, et croît linéairement avec le nombre d'instantanés. Pour vérifier si c'est le cas, vous pouvez essayer de chronométrer un zfs snapshot sur le système de fichiers directement et d'effectuer un zfs list -t all sur le système de fichiers et ses instantanés, et de voir lequel prend beaucoup plus de temps que l'autre ( devrait être le deuxième).
Dans la communauté ZFS, il s’agit d’un problème connu, mais c’est difficile à résoudre, car il faudrait modifier de nombreuses structures de métadonnées sur disque pour l’améliorer. Conserver autant d’instantanés est plutôt inhabituel. Si lxd faisait de son mieux pour éviter de répertorier tous les instantanés nécessaires à son exécution, je pense que cela pourrait résoudre votre problème.
Alternativement, vous pouvez prendre des instantanés toutes les 5 minutes, mais les supprimer assez rapidement et ne conserver (par exemple) que des instantanés de 5m, 10m, 15m, 30m, 1h, 2h, 3h, 6h, 12h, 24h, etc. Cela vous donne une haute résolution pendant la fenêtre quand il est le plus probable que vous en avez besoin, et cela ne ralentirait pas non plus lxd snapshot.