web-dev-qa-db-fra.com

Diminution du taux de transfert lors de la copie de grandes quantités de données

J'utilise un système Ubuntu 16.04.3 LTS (4.10.0-40-generic) avec deux disques durs et plusieurs partitions sur chaque disque. Lorsque je copie des données (<5 Go) entre les deux disques, le taux de transfert est d’environ 70 Mo/s. Cependant, lorsque j'essaie de copier une grande quantité de données (> 30 Go) d'un disque à un autre, je constate plusieurs problèmes de performances.

Ma question est de savoir si ce comportement est normal et prévisible dans les systèmes Linux?
Quelqu'un peut-il m'expliquer cela et me dire comment éviter cette baisse de performance?

Ci-dessous, je vais décrire mes observations. Dans l'exemple, j'ai copié un fichier image disque de 54 Go de sda8 (partition de 325 Go) vers sdb8 (partition de 1,6 To)

1) Le taux de transfert diminue et iowait augmente
Lorsque j'essaie de copier plus de 50 Go, je remarque que le taux de transfert diminue progressivement. Je surveille la performance en utilisant des regards, au sommet, iotop et iostat. Avec une progression de 30 Go, le taux de transfert a chuté à 58 Mo/s, entre 46 Go et 36 Mo/s, entre 52 et 12 Mo/s. Après cela, le taux de transfert commence réellement à fluctuer et tombe en dessous de 1 Mo/s. Dans le même temps, je constate que iowait augmente initialement de 0% à 62%. Pendant la copie du disque, sd8 a un pourcentage d'occupation entre 40% et 60%. Le disque sdb est occupé à 100% tout le temps. Non seulement le taux de transfert diminue, mais mon système devient moins réactif. Je m'attends à ce que le iowait en soit la cause.
Est-ce un comportement normal? Comment éviter la baisse de performance?

2) IOwait reste élevé après la copie
Lorsque la copie est terminée, je constate que iowait est toujours élevé et commence progressivement à revenir à la normale. Cela prend quelques minutes. Je pense que pendant ce temps, les données sont toujours écrites sur sdb à un débit d'environ 1 ou 2 Mo/s. Avec iotop, il semble que le processus "jdb2/sdb4-8" provoque cette écriture sur le disque. Pendant la période de baisse de IOwait, mon système souffre toujours d'une mauvaise réactivité. On voit également que le disque sda ​​n’est plus occupé, mais que le disque sdb fonctionne toujours à 100%.
Qu'est-ce qui cause la mauvaise réactivité de mon système quelques minutes après la copie?
Cela peut-il être évité?

) La copie depuis un lecteur réseau augmente les effets
Lorsque j'essaie de copier de mon Synology NAS sur mon disque local (sdb8), les effets sont encore pires. Tout d’abord, le lecteur réseau est monté sur mon système, puis la copie est lancée. Initialement, un taux de transfert de 70 Mo/s est également réalisé, mais le taux de transfert chute moins vite. Après quelques Go, le taux de transfert est tombé bien en dessous de 1 Mo/s. La copie a été essayée en utilisant le glisser-déposer de Nautilus, la commande "cp", la commande rsync, l'application FreeFileSync, mais tous ont affiché des performances médiocres.
Quelle pourrait être la cause de l’aggravation des effets de baisse des performances avec les lecteurs réseau?

informations complémentaires
Pendant la copie, "iostat-dx 5" était utilisé pour surveiller les performances du disque. Environ 5 Go de suivi de l’avancement de la copie montrent:

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0,00     0,00  530,40    0,00 68064,80     0,00   256,65     1,62    3,06    3,06    0,00   1,63  86,72
sdb               0,00 18767,20    0,20  112,40    23,20 73169,60  1300,05   144,32 1345,39  308,00 1347,23   8,88 100,00

Lorsque la copie a atteint environ 52 Go, cela indique:

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0,00     0,00   64,60    0,00  8268,80     0,00   256,00     0,22    3,41    3,41    0,00   1,76  11,36
sdb               0,00  1054,40    0,20   10,60     6,40  6681,60  1238,52   148,56 9458,00    0,00 9636,45  92,59 100,00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0,00     0,00   50,20    0,00  6425,60     0,00   256,00     0,16    3,09    3,09    0,00   1,64   8,24
sdb               0,00  2905,80    0,40   17,00     8,80 10289,60  1183,72   141,86 10199,77  652,00 10424,42  57,47 100,00

Je me rends compte que ces questions sont multiples, mais je soupçonne qu’elles sont toutes liées à la même cause et espère que quelqu'un pourra me clarifier la situation.

7
user3074126

Malheureusement, cela est normal et prévu pour votre cas d'utilisation de gros fichiers. Votre cas de deux disques durs et d’un fichier 50G + élimine de nombreuses discussions trompeuses sur les "périphériques lents", les "bus lents" et les "systèmes de fichiers lents" et vous laisse le problème inexpliqué d’une copie lente. Vous devez avoir un peu de mémoire pour obtenir les performances que vous avez pour les fichiers 30G. Les tampons système sont utilisés, remplis et, une fois votre commande de copie terminée, finissent par être vidés à la cible, ce qui complique quelque peu la cadence réelle (même la commande "time" se terminera bien avant que les tampons ne soient enfin vidés.

La seule "solution de contournement" que j'ai trouvée consiste à utiliser une commande "copie" qui vous permet de configurer vous-même des tampons explicites, comme le font tar ou cpio. Définir une mémoire tampon de 2M sur tar m'a permis d'accélérer la copie d'un fichier 50G à 10 M/s à environ 35 M/s, ce qui est encore beaucoup plus lent que la valeur nominale de 100 M/s obtenue sur des fichiers plus petits (ou sous Windows).

1
ubfan1