Re: [FRsAG] Proxmox 6.2 : lenteur vzdump + très faible occupation CPU de pigz

2020-11-10 Par sujet Guillaume LUCAS 

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. :)
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox 6.2 : lenteur vzdump + très faible occupation CPU de pigz

2020-11-10 Par sujet Emmanuel DECAEN 
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*

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox 6.2 : lenteur vzdump + très faible occupation CPU de pigz

2020-11-10 Par sujet David Ponzone 
>> 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 ?).

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox 6.2 : lenteur vzdump + très faible occupation CPU de pigz

2020-11-10 Par sujet Guillaume LUCAS 

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.
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox 6.2 : lenteur vzdump + très faible occupation CPU de pigz

2020-11-10 Par sujet Rodolphe RIDEL 
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-h330-mini-disk-controller.57392/).
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-performances-des-contr%C3%B4leurs-raid-sans-cache-h330-h310-s130-s110-s300-s100-h200-sas-6-ir-sas-5-ir?lang=fr).

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 ;) 
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox 6.2 : lenteur vzdump + très faible occupation CPU de pigz

2020-11-10 Par sujet David Ponzone 

> Le 10 nov. 2020 à 11:42, Guillaume LUCAS  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 ?

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox 6.2 : lenteur vzdump + très faible occupation CPU de pigz

2020-11-10 Par sujet Guillaume LUCAS 

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 ?

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox 6.2 : lenteur vzdump + très faible occupation CPU de pigz

2020-11-10 Par sujet David Ponzone 

> Le 10 nov. 2020 à 11:24, Guillaume LUCAS  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 ?


___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox 6.2 : lenteur vzdump + très faible occupation CPU de pigz

2020-11-10 Par sujet Guillaume LUCAS 

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  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 
> 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/

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox 6.2 : lenteur vzdump + très faible occupation CPU de pigz

2020-11-09 Par sujet Christophe Nouvel via FRsAG 
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  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  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/
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox 6.2 : lenteur vzdump + très faible occupation CPU de pigz

2020-11-09 Par sujet Kevin LABECOT 
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  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/

Re: [FRsAG] Proxmox 6.2 : lenteur vzdump + très faible occupation CPU de pigz

2020-11-09 Par sujet David Ponzone 
Euh t’as comparé tes perfs NFS depuis chaque serveur ?

> Le 9 nov. 2020 à 18:36, Guillaume LUCAS  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.
> 

___
Liste de diffusion du FRsAG
http://www.frsag.org/