Forum Linux.noyau Lenteur lors de la copie de gros fichiers

Posté par  .
Étiquettes :
3
25
mar.
2010
Bonjour,

Lorsque j'effectue une copie de fichier de taille importante (3Gio) d'un disque dur vers l'autre, la copie est très lente (10Mio/s max) et le PC se traine la nouille (wa à 90% dans top).

Si j'effectue une copie d'un fichier de taille plus modeste (700Mio), c'est très rapide : 70Mio/s en moyenne.

J'ai essayé de jouer avec les fichiers /sys/block/sd[ab]/queue/scheduler mais je n'obtiens pas bien meilleurs résultats.

Je n'ai trouvé ni explications ni contournement au problème.

Je suis sous Debian Squeeze avec un Noyau 2.6.32-5.
Le PC est un Core 2 Duo avec 2Go de ram, un disque dur SATA, un disque dur eSATA, et le AHCI est activé.

  • # Re:

    Posté par  . Évalué à 3.

    C'est peut-être normal.
    C'est rapide pour les petits fichiers à cause du cache. Pour les gros fichiers le cache ne change pas grand chose.
    Vérifies sommairement les performances des disques avec "hdparm -t /dev/...".

    • [^] # Re: Re:

      Posté par  . Évalué à 2.

      hdparm me donne de bon résultat.
      De quel cache parles-tu ? Car les petits fichiers dont je parle font 700Mio !

      • [^] # Re: Re:

        Posté par  (site web personnel) . Évalué à 2.

        Le PC est un Core 2 Duo avec 2Go de ram

        Donc pour peu que les autres applications utilisées en même temps utilisent moins de 1.3Go (très probable), tes petits fichiers de 700Mio tiennent bien au chaud dans le cache. Essaie de faire la corrélation entre la valeurs donnée par free(1) avant la copie (le chiffre free + buffers/cache) et la taille des fichiers à partir de laquelle les taux de transferts s'écroulent.

  • # Fragmentation?

    Posté par  . Évalué à 3.

    Bonjour,

    Tout d'abord, tu ne précise pas si tu fais une copie au sein du meme disque dur ou entre deux disques. Dans le cas d'une copie sur le même disque, les performances sont assez bridées.

    Ensuite, tu n'a pas de problème pour manipuler un fichier de 700mo, mais du mal a manipuler un fichier de 3Go. Dans le principe, copier un bon gros paquet de données bien grasses, ca ne pose pas plus de problème que ca, sauf s'il faut les bazarder a droite et a gauche. Les systèmes de fichiers ext la gère relativement bien, sauf si ta partition est proche de la saturation : combien y'a t'il d'espace libre sur ton disque dur destination?

    • [^] # Re: Fragmentation?

      Posté par  . Évalué à 2.

      tu ne précise pas si tu fais une copie au sein du même disque dur ou entre deux disques
      Si si : Lorsque j'effectue une copie de fichier [...] d'un disque dur vers l'autre

      sda : ma source en ext3
      sdb : ma destination en ext4
      $ df -h /dev/sd[ab][16]
      Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
      /dev/sda1 92G 6,9G 81G 8% /
      /dev/sda6 825G 736G 47G 95% /home
      /dev/sdb1 917G 425G 446G 49% /media/1To

  • # eSata <--> sata

    Posté par  . Évalué à 1.

    ton problème peut avoir multiples causes.

    Fichier fortement fragmenté

    Multiples défauts de cache ce qui implique des accès disques, et si fichier fragmenté..

    Peut-être un problème d'alignement entre les blocs physiques et logiques ? Ton disque externe utilise t'il des blocs physiques de 512 octets ou bien de 4Kio ?

    Peut-être qu'en réalignant les blocs avec fdisk tu arriveras à de meilleurs résultats, voir ci-dessous :

    http://www.tcpdump.com/kb/virtualization/vmware-esx-server/v(...)

    • [^] # Re: eSata <--> sata

      Posté par  . Évalué à 1.

      Fichier fortement fragmenté
      J'ai interrogé mes fichiers avec filefrag, et il me répond ça : "perfection would be 1 extents" (je suppose que c'est pas trop mal!)

      Multiples défauts de cache
      Comment on le voit ça , de quel cache tu parles ?

      Ton disque externe utilise t'il des blocs physiques de 512 octets ou bien de 4Kio ?
      J'essais de trouver comment on fait pour l'interroger et je te répond ce soir.

      en réalignant les blocs avec fdisk
      Ce qui veut dire tout effacer ?

      • [^] # Re: eSata <--> sata

        Posté par  . Évalué à 1.

        défaut de cache = c'est quand la donnée ne se trouve pas dans le cache et qu'un accès disque est nécessaire.

        comment les voir sous linux, aucune idée, d'une je bosse sur aix et plus sous linux, de deux j'ai la flemme de chercher :)

        Réaligner les blocs avec fdisk implique surtout de faire un backup avant :) donc oui en somme

      • [^] # profiling

        Posté par  (site web personnel) . Évalué à 2.

        Tu peux voir sur quoi ça attend avec sleepingBeauties.stp et/ou blktrace par exemple.

        http://sourceware.org/systemtap/examples/keyword-index.html#(...)
        http://git.kernel.dk/?p=blktrace.git;a=blob;f=README

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: profiling

          Posté par  . Évalué à 1.

          J'ai eu la brillante idée de lancer un fsck sur mon disque dur e-sata (fsck c'est magique ça arrange tout !)
          Résultat : la partition n'est plus que partiellement lisible, je pense que soit mon disque dur a un défaut physique, soit ext4 n'est pas si stable que ça.

          Bref, j'ai pommé environ 500Go de données.

          Merci tout de même pour votre aide.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.