Proxmox 6.2 : lenteur vzdump + très faible occupation CPU de pigz
Bonjour, Nous avons deux clusters Proxmox. L'un en version 4.4, l'autre en 6.2. Nous avons migré nos VMs de l'un à l'autre (4.4 = > 6.2). La plupart de nos VMs occupent moins de 20 Go. Nous avons quelques rares VMs dont le disque dur atteint 1 To. Chaque nuit, un script maison fait un vzdump --pigz de toutes nos VMs. La destination est un MÊME montage NFS . Nous utilisons vzdump -mode snapshot -compress gzip -pigz 1 -dumpdir $ partage _NFS $ VMID : * En moyenne, le débit est de ~ 137 Mo /s sur l e cluster Proxmox en version 4.4 ; * En moyenne, le débit est de ~ 31 Mo /s sur le cluster Proxmox en version 6.2 . Le s serveurs sous Proxmox 6.2 sont plus récent s ( 2 CPU de 64 thread s, 754 Go de RAM) que c eux en version 4.4 (2 CPU de 32 thread s, 300Go de RAM) , donc ils devraient fournir un débit supérieur ou égal . Ce n'est pas le cas. Nous utilisons -pigz 1 : * Sur l'ancien cluster, on constate, avec htop, que la moitié des cœurs CPU est utilisée à 100 % tout le long du vzdump ; * Sur le nouveau cluster, la moitié des cœurs CPU est utilisée durant les 5 premières secondes du vzdump, après quoi, l'occupation CPU est invisible. On a joué avec les options -compress, -pigz, -zstd : on a toujours un débit inférieur et une occupation CPU moindre à ce que l'on a sous P roxmox 4.4 . Le paquet pigz est installé. La version de pigz est plus récente sur les nouveaux Proxmox. Remplacer le binaire par celui des anciens Proxmox n'apporte pas de résultat. Quelqu'un a une idée ? Bonne fin de journée.
Euh t’as comparé tes perfs NFS depuis chaque serveur ?
Le 9 nov. 2020 à 18:36, Guillaume LUCAS <guillaume.lucas@univ-avignon.fr> a écrit :
Bonjour,
Nous utilisons vzdump -mode snapshot -compress gzip -pigz 1 -dumpdir $partage_NFS $VMID : * En moyenne, le débit est de ~137 Mo/s sur le cluster Proxmox en version 4.4 ; * En moyenne, le débit est de ~31 Mo/s sur le cluster Proxmox en version 6.2. Les serveurs sous Proxmox 6.2 sont plus récents (2 CPU de 64 threads, 754 Go de RAM) que ceux en version 4.4 (2 CPU de 32 threads, 300Go de RAM), donc ils devraient fournir un débit supérieur ou égal. Ce n'est pas le cas.
Bonsoir, Tu n'aurais pas customizé vzdump.conf sur le proxmox 4 ? (comme le tmpdir) — Kevin Labécot
Le 9 nov. 2020 à 18:36, Guillaume LUCAS <guillaume.lucas@univ-avignon.fr> a écrit :
Bonjour,
Nous avons deux clusters Proxmox. L'un en version 4.4, l'autre en 6.2. Nous avons migré nos VMs de l'un à l'autre (4.4 = > 6.2). La plupart de nos VMs occupent moins de 20 Go. Nous avons quelques rares VMs dont le disque dur atteint 1 To. Chaque nuit, un script maison fait un vzdump --pigz de toutes nos VMs. La destination est un MÊME montage NFS.
Nous utilisons vzdump -mode snapshot -compress gzip -pigz 1 -dumpdir $partage_NFS $VMID : * En moyenne, le débit est de ~137 Mo/s sur le cluster Proxmox en version 4.4 ; * En moyenne, le débit est de ~31 Mo/s sur le cluster Proxmox en version 6.2. Les serveurs sous Proxmox 6.2 sont plus récents (2 CPU de 64 threads, 754 Go de RAM) que ceux en version 4.4 (2 CPU de 32 threads, 300Go de RAM), donc ils devraient fournir un débit supérieur ou égal. Ce n'est pas le cas.
Nous utilisons -pigz 1 : * Sur l'ancien cluster, on constate, avec htop, que la moitié des cœurs CPU est utilisée à 100 % tout le long du vzdump ; * Sur le nouveau cluster, la moitié des cœurs CPU est utilisée durant les 5 premières secondes du vzdump, après quoi, l'occupation CPU est invisible.
On a joué avec les options -compress, -pigz, -zstd : on a toujours un débit inférieur et une occupation CPU moindre à ce que l'on a sous Proxmox 4.4. Le paquet pigz est installé. La version de pigz est plus récente sur les nouveaux Proxmox. Remplacer le binaire par celui des anciens Proxmox n'apporte pas de résultat.
Quelqu'un a une idée ?
Bonne fin de journée. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Et si le bottleneck était à la source? Sur quel storage sont stockés les disques des VMs? Et franchement, pour résoudre tous ces problèmes qui sollicitent fortement les stockages : installé un proxmox BackUp server et le tour est joué! Spectaculaire! Bonne journée, Christophe Nouvel. Envoyé de mon iPhone
Le 9 nov. 2020 à 19:03, Kevin LABECOT <kevin@labecot.fr> a écrit :
Bonsoir, Tu n'aurais pas customizé vzdump.conf sur le proxmox 4 ? (comme le tmpdir)
— Kevin Labécot
Le 9 nov. 2020 à 18:36, Guillaume LUCAS <guillaume.lucas@univ-avignon.fr> a écrit :
Bonjour,
Nous avons deux clusters Proxmox. L'un en version 4.4, l'autre en 6.2. Nous avons migré nos VMs de l'un à l'autre (4.4 = > 6.2). La plupart de nos VMs occupent moins de 20 Go. Nous avons quelques rares VMs dont le disque dur atteint 1 To. Chaque nuit, un script maison fait un vzdump --pigz de toutes nos VMs. La destination est un MÊME montage NFS.
Nous utilisons vzdump -mode snapshot -compress gzip -pigz 1 -dumpdir $partage_NFS $VMID : * En moyenne, le débit est de ~137 Mo/s sur le cluster Proxmox en version 4.4 ; * En moyenne, le débit est de ~31 Mo/s sur le cluster Proxmox en version 6.2. Les serveurs sous Proxmox 6.2 sont plus récents (2 CPU de 64 threads, 754 Go de RAM) que ceux en version 4.4 (2 CPU de 32 threads, 300Go de RAM), donc ils devraient fournir un débit supérieur ou égal. Ce n'est pas le cas.
Nous utilisons -pigz 1 : * Sur l'ancien cluster, on constate, avec htop, que la moitié des cœurs CPU est utilisée à 100 % tout le long du vzdump ; * Sur le nouveau cluster, la moitié des cœurs CPU est utilisée durant les 5 premières secondes du vzdump, après quoi, l'occupation CPU est invisible.
On a joué avec les options -compress, -pigz, -zstd : on a toujours un débit inférieur et une occupation CPU moindre à ce que l'on a sous Proxmox 4.4. Le paquet pigz est installé. La version de pigz est plus récente sur les nouveaux Proxmox. Remplacer le binaire par celui des anciens Proxmox n'apporte pas de résultat.
Quelqu'un a une idée ?
Bonne fin de journée. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Le 09/11/2020 à 18:50, David Ponzone a écrit :
Euh t’as comparé tes perfs NFS depuis chaque serveur ?
Non. Mais c'est le même montage NFS. Le même switch au milieu. Les mêmes optiques 10 G, etc. Le 09/11/2020 à 19:02, Kevin LABECOT a écrit :
Tu n'aurais pas customizé vzdump.conf sur le proxmox 4 ? (comme le tmpdir)
Non, le vzdump.conf est celui par défaut, donc vzdump utilise les arguments que l'on passe sur la ligne de commande. Le 10/11/2020 à 07:13, Christophe Nouvel a écrit :
Et si le bottleneck était à la source? Sur quel storage sont stockés les disques des VMs?
Stockage local. LVM sur un RAID matériel. Cluster Proxmox 4 = PERC H730P Mini 2 Go de cache. Cluster Proxmox 6 = PERC H330 Mini sans cache.
Et franchement, pour résoudre tous ces problèmes qui sollicitent fortement les stockages : installé un proxmox BackUp server et le tour > est joué! Spectaculaire!
Nous ne connaissons pas. On va regarder. C'est une nouveauté Proxmox 6 ? Bonne journée. Le 10/11/2020 à 07:13, Christophe Nouvel a écrit :
Bonjour, Et si le bottleneck était à la source? Sur quel storage sont stockés les disques des VMs?
Et franchement, pour résoudre tous ces problèmes qui sollicitent fortement les stockages : installé un proxmox BackUp server et le tour est joué! Spectaculaire!
Bonne journée,
Christophe Nouvel.
Envoyé de mon iPhone
Le 9 nov. 2020 à 19:03, Kevin LABECOT <kevin@labecot.fr> a écrit :
Bonsoir, Tu n'aurais pas customizé vzdump.conf sur le proxmox 4 ? (comme le tmpdir)
— Kevin Labécot
Le 9 nov. 2020 à 18:36, Guillaume LUCAS <guillaume.lucas@univ-avignon.fr <mailto:guillaume.lucas@univ-avignon.fr>> a écrit :
Bonjour,
Nous avons deux clusters Proxmox. L'un en version 4.4, l'autre en 6.2. Nous avons migré nos VMs de l'un à l'autre (4.4 = > 6.2). La plupart de nos VMs occupent moins de 20 Go. Nous avons quelques rares VMs dont le disque dur atteint 1 To. Chaque nuit, un script maison fait un vzdump --pigz de toutes nos VMs. La destination est unMÊMEmontage NFS.
Nous utilisons vzdump -mode snapshot -compress gzip -pigz 1 -dumpdir $partage_NFS $VMID : * En moyenne, le débit est de ~137Mo/s sur le cluster Proxmoxen version 4.4; * En moyenne, le débit estde ~31Mo/s sur le cluster Proxmoxen version 6.2. Les serveurssous Proxmox6.2 sontplus récents(2 CPUde 64 threads, 754Go de RAM) que ceuxen version 4.4 (2CPUde 32 threads,300Go de RAM), donc ils devraient fournir un débit supérieur ou égal. Ce n'est pas le cas.
Nous utilisons -pigz 1 : * Sur l'ancien cluster, on constate, avec htop, que la moitié des cœurs CPU est utilisée à 100 % tout le long du vzdump ; * Sur le nouveau cluster, la moitié des cœurs CPU est utilisée durant les 5 premières secondes du vzdump, après quoi, l'occupation CPU est invisible.
On a joué avec les options -compress, -pigz, -zstd: on a toujours un débit inférieur et une occupation CPU moindre à ce que l'on a sousProxmox 4.4. Le paquet pigz est installé. La version de pigz est plus récente sur les nouveaux Proxmox. Remplacer le binaire par celui des anciens Proxmox n'apporte pas de résultat.
Quelqu'un a une idée ?
Bonne fin de journée. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 10 nov. 2020 à 11:24, Guillaume LUCAS <guillaume.lucas@univ-avignon.fr> a écrit :
Bonjour,
Le 09/11/2020 à 18:50, David Ponzone a écrit :
Euh t’as comparé tes perfs NFS depuis chaque serveur ?
Non. Mais c'est le même montage NFS. Le même switch au milieu. Les mêmes optiques 10 G, etc.
Ok mais le test de base prend 30 sec avec fio, dd, voir cp. Parce que la théorie et la pratique, parfois… Autre chose: tu es sûr qu’aucun autre job occupe le NAS au moment où tu fais le backup ?
Le 10/11/2020 à 07:13, Christophe Nouvel a écrit :
Et si le bottleneck était à la source? Sur quel storage sont stockés les disques des VMs?
Stockage local. LVM sur un RAID matériel. Cluster Proxmox 4 = PERC H730P Mini 2 Go de cache. Cluster Proxmox 6 = PERC H330 Mini sans cache.
Ah 2Go de cache sur celui qui pédale bien et pas de cache sur celui qui rame, ça me semble déjà être une différence non ?
Le 10/11/2020 à 11:32, David Ponzone a écrit :
Ok mais le test de base prend 30 sec avec fio, dd, voir cp. Parce que la théorie et la pratique, parfois…
Yep. On a bien noté de tester. Après, perso, je peine toujours à interpréter les résultats de dd, hdparm & co. Avec dd, en fonction des valeurs des arguments bs, conv, etc., j'obtiens toujours tout et son contraire, et pas forcément les conditions réelles (notamment avec bs).
Autre chose: tu es sûr qu’aucun autre job occupe le NAS au moment où tu fais le backup ?
Sûr, non, car le principe d'un NAS est d'être toujours sollicité par les trouzemilles composants d'un SI, mais, on a constaté et testé : nos vzdump pédalent à toute heure du jour et de nuit. À plusieurs moments, on a regardé les graphes IO/s du NAS : il faisait rien.
Stockage local. LVM sur un RAID matériel. Cluster Proxmox 4 = PERC H730P Mini 2 Go de cache. Cluster Proxmox 6 = PERC H330 Mini sans cache.
Ah 2Go de cache sur celui qui pédale bien et pas de cache sur celui qui rame, ça me semble déjà être une différence non ?
La lecture (source du vzdump) est le stockage local sus-décrit, l'écriture se fait sur le NFS. Le cache RAID est utilisé en écriture uniquement (donc inutile dans le cas présent), non ?
Le 10 nov. 2020 à 11:42, Guillaume LUCAS <guillaume.lucas@univ-avignon.fr> a écrit :
Le 10/11/2020 à 11:32, David Ponzone a écrit :
Ok mais le test de base prend 30 sec avec fio, dd, voir cp. Parce que la théorie et la pratique, parfois…
Yep. On a bien noté de tester. Après, perso, je peine toujours à interpréter les résultats de dd, hdparm & co. Avec dd, en fonction des valeurs des arguments bs, conv, etc., j'obtiens toujours tout et son contraire, et pas forcément les conditions réelles (notamment avec bs).
Oui je suis d'accord mais tu peux comparer les 2, c’est un début. Sur un simple dd/cp tu seras fixé vu l’écart de perfs que tu constates. Mais je ferais plutôt un dd venant de /dev/zero car un cp venant de ton LVM local permettra pas de savoir si problème sur le LVM local en read ou sur le NFS en write.
Stockage local. LVM sur un RAID matériel. Cluster Proxmox 4 = PERC H730P Mini 2 Go de cache. Cluster Proxmox 6 = PERC H330 Mini sans cache. Ah 2Go de cache sur celui qui pédale bien et pas de cache sur celui qui rame, ça me semble déjà être une différence non ?
La lecture (source du vzdump) est le stockage local sus-décrit, l'écriture se fait sur le NFS. Le cache RAID est utilisé en écriture uniquement (donc inutile dans le cas présent), non ?
Hmm dans la conf de la PERC tu dois avoir un truc qui s’appelle read-ahead. Vérifie que c’est bien activé sur les 2. Et aussi, c quoi comme RAID en dessous ? 1, 5, 6, 10 ? Pareil sur les 2 ? Même nombre de HD dans les 2 cas ?
Bonjour à tous, les PERC H330 sont connus pour avoir été de grosses sources de problèmes avec de nombreuses solutions de virtualisation (vmware, vsan, proxmox, etc) comme ici par exemple : (https://forum.proxmox.com/threads/problems-with-dell-poweredge-r430-perc-h33...). On trouve encore pas mal de sujets là-dessus. De plus, Dell a une entrée sur les contrôleurs PERC sans cache dans leur KB qui explique bien que l'on peut avoir des surprises (https://www.dell.com/support/article/fr-fr/sln164091/perc-probl%C3%A8mes-de-...). Est-ce que les firmwares des PERC et ceux des disques sont bien à jour sur ces machines et est-il possible monter les anciens PERC H730P à la place des H330 ? Cela pourrait être une solution. Bonnes chances pour la suite en tous cas ;)
Le 10/11/2020 à 13:06, David Ponzone a écrit :
Mais je ferais plutôt un dd venant de /dev/zero car un cp venant de ton LVM local permettra pas de savoir si problème sur le LVM local en read ou sur le NFS en write.
Pour être plus proche de la prod', je compte faire le vzdump d'une petite VM dans un tmpfs.
Stockage local. LVM sur un RAID matériel. Cluster Proxmox 4 = PERC H730P Mini 2 Go de cache. Cluster Proxmox 6 = PERC H330 Mini sans cache. Ah 2Go de cache sur celui qui pédale bien et pas de cache sur celui qui rame, ça me semble déjà être une différence non ?
La lecture (source du vzdump) est le stockage local sus-décrit, l'écriture se fait sur le NFS. Le cache RAID est utilisé en écriture uniquement (donc inutile dans le cas présent), non ?
Hmm dans la conf de la PERC tu dois avoir un truc qui s’appelle read-ahead. Vérifie que c’est bien activé sur les 2.
megacli dit : activé sur l'ancien cluster (mode adaptative pour être précis), désactivé sur le nouveau cluster. C'est grave, docteur ?
Et aussi, c quoi comme RAID en dessous ? 1, 5, 6, 10 ? Pareil sur les 2 ?
RAID 5. Pareil dans les deux clusters.
Même nombre de HD dans les 2 cas ?
8 (0 spare) disques 10 ktr/min dans l'ancien cluster, 10 (9 + 1 spare) disques 10 k dans le nouveau.
Hmm dans la conf de la PERC tu dois avoir un truc qui s’appelle read-ahead. Vérifie que c’est bien activé sur les 2.
megacli dit : activé sur l'ancien cluster (mode adaptative pour être précis), désactivé sur le nouveau cluster. C'est grave, docteur ?
Difficile d’être sûr mais en tout cas c’est une différence: Ancien cluster avec 2Go de cache et read-ahead Nouveau cluster avec carte PERC la plus pourrie du marché, pas de cache, donc pas de read-ahead. Mais ceci dit, regarder sur Google, la H330 est une grosse grosse bouze, comme Dell sait en mettre de temps en temps sur des serveurs de milieu de gamme (au hasard, R3XX ou R4XX ?).
Bonsoir, Le 10/11/2020 à 15:52, David Ponzone a écrit :
Hmm dans la conf de la PERC tu dois avoir un truc qui s’appelle read-ahead. Vérifie que c’est bien activé sur les 2. megacli dit : activé sur l'ancien cluster (mode adaptative pour être précis), désactivé sur le nouveau cluster. C'est grave, docteur ?
Difficile d’être sûr mais en tout cas c’est une différence: Ancien cluster avec 2Go de cache et read-ahead Nouveau cluster avec carte PERC la plus pourrie du marché, pas de cache, donc pas de read-ahead.
Mais ceci dit, regarder sur Google, la H330 est une grosse grosse bouze, comme Dell sait en mettre de temps en temps sur des serveurs de milieu de gamme (au hasard, R3XX ou R4XX ?).
Si c'est la carte avec un iostat, on doit voir le disque qui sature: Dans l'exemple ci-dessous, on voit sdb à 60% d'utilisation avec 30 Mo/s en écriture et 176 Mo/s en lecture sur un vieux serveur Dell de 2010: # iostat -xm 10 Device r/s w/s rMB/s wMB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util sdb 121.30 750.20 29.48 176.24 0.10 0.00 0.08 0.00 6.52 8.55 5.44 248.88 240.56 0.69 59.92 sda 0.60 9.80 0.07 0.11 0.00 7.00 0.00 41.67 6.17 3.05 0.02 128.00 11.59 1.96 2.04 Et si le problème n'est pas au niveau disque mais sur le NFS, il peut-être intéressant de changer la carte réseau et surtout le câble réseau utilisé (fibre, twinax, cuivre ?) sur le nouveau serveur. Ceci étant pour les performances, le passage de LVM à Ceph améliore bien les chose. Depuis le passage sur Ceph avec Proxmox 6, et malgré une vieille carte PERC6 RAID + de très vieux disques SAS, les débits réels Ceph sont très sympas : entre 300 et 400 Mo/s en écriture. Et je ne parle même pas de la résistance aux pannes ;-) Bon courage. -- *Emmanuel DECAEN*
Le 10/11/2020 à 15:28, Guillaume LUCAS a écrit :
Pour être plus proche de la prod', je compte faire le vzdump d'une petite VM dans un tmpfs.
Bon, ben, je pense que ça plie le débat. Sur le nouveau cluster (Proxmox 6, PERC H330 Mini) : * vzdump -pigz 1 d'une VM depuis RAID+LVM vers un montage tmpfs : lecture = 20 mo/s ; écriture = 30 mo/s ; occupation CPU pigz = < 100 %, 200 % au mieux ; temps de sauvegarde : 5 m 30 ; * On clone cette VM dans un storage de type directory qui s'avère être le tmpfs ; * vzdump -pigz 1 de cette VM depuis tmpfs vers tmpfs : lecture = 200 mo/s ; écriture = 120 mo/s ; occupation CPU pigz > 900 % tout au long du dump ; temps de sauvegarde = 24 secs ; * Même vzdump, même VM tmpfs vers notre montage NFS habituel : lecture = 200 mo/s ; écriture = 130 mo/s ; occupation CPU pigz > 600 % tout du long ; temps de sauvegarde : 20 secs. Je conclus sur une lenteur du RAID dans nos nouveaux hyperviseurs. Confirmation / infirmation ? Le 10/11/2020 à 15:16, Rodolphe RIDEL a écrit :
les PERC H330 sont connus pour avoir été de grosses sources de problèmes avec de nombreuses solutions de virtualisation
Intéressant, en effet. Merci pour les pointeurs.
Est-ce que les firmwares des PERC et ceux des disques sont bien à jour sur ces machines et est-il possible monter les anciens PERC H730P à la place des H330 ? Cela pourrait être une solution.
Non, nous ne sommes pas à jour (25.5.5 alors que 25.5.6 est dispo, a minima). Pas possible de récupérer les H730P car ils sont encore en prod. Le 10/11/2020 à 15:52, David Ponzone a écrit :
Mais ceci dit, regarder sur Google, la H330 est une grosse grosse bouze, comme Dell sait en mettre de temps en temps sur des serveurs de milieu de gamme (au hasard, R3XX ou R4XX ?).
(Perdu :) : R640) Le 10/11/2020 à 18:15, Emmanuel DECAEN a écrit :
Si c'est la carte avec un iostat, on doit voir le disque qui sature:
Sans vzdump, avec notre charge à 21 h : 30-50 % d'utilisation ; < 1 mo/s en lecture ; 1-3 mo/s en écriture ; 100-200 w/s ; < 0,10 iowait . Avec un vzdump en plus : 70-85 % d'utilisation ; 30-70 mo/s de lecture ; 2-4 mo/s en écriture ; 800-1500 r/s ; 84-120 w/s ; < 0.10 iowait . Toutefois, attention, le man expose : %util […] But for devices serving requests in parallel, such as RAID arrays and modern SSDs, this number does not reflect their performance limits. Merci à tous. :)
participants (6)
-
Christophe Nouvel -
David Ponzone -
Emmanuel DECAEN -
Guillaume LUCAS -
Kevin LABECOT -
Rodolphe RIDEL