Forum Linux.général Reconstruction du raid super lente

Posté par  (site web personnel) .
Étiquettes :
0
2
août
2011

Bonjour tous,

J'ai un petit serveur (perso) qui est monté en raid + lvm. Le raid qui m'intéresse est un raid5 sur 3 disques sata.
Suite à une petite coupure de courant, un disque n'est pas correctement remonté. Enfin si, mais mon raid tourne sur deux pattes seulement.
J'ai donc voulu reconstruire mon raid en ajoutant la partition, mais là l'ordi devient carrément inutilisable :
le load de la machine monte à quasi 4
et surtout, la reconstruction est super super lente, j'arrive pas à dépasser les 750ko/s et il m'indique de l'ordre de 5500 - 6000 minutes de reconstruction...

Comment on reconstruit un raid sans rendre la machine inutilisable et dans des temps corrects ? Genre une nuit si besoin, mais pas 3 jours.

J'ai essayé de jouer avec /proc/sys/dev/raid/speed_limit_min mais cela n'a aucun effet.

Voici quelques sorties pour infos.
partition déconnectée :

# mdadm --detail /dev/md2
/dev/md2:
        Version : 0.90
  Creation Time : Mon Jun 25 00:32:13 2007
     Raid Level : raid5
     Array Size : 483363456 (460.97 GiB 494.96 GB)
  Used Dev Size : 241681728 (230.49 GiB 247.48 GB)
   Raid Devices : 3
  Total Devices : 2
Preferred Minor : 2
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Aug  2 09:14:35 2011
          State : active, degraded
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : 7e6c101a:09efb900:6ad65a8a:45815ce7
         Events : 0.85486

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       23        1      active sync   /dev/sdb7
       2       8       39        2      active sync   /dev/sdc7

# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active raid5 sdb7[1] sdc7[2]
      483363456 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU]
      bitmap: 31/231 pages [124KB], 512KB chunk

# cat /proc/sys/dev/raid/speed_limit_min
50000
# cat /proc/sys/dev/raid/speed_limit_max
100000

Disque en cours de reconstruction :

# mdadm /dev/md2 --re-add /dev/sda7
mdadm: re-added /dev/sda7
# mdadm --detail /dev/md2
/dev/md2:
        Version : 0.90
  Creation Time : Mon Jun 25 00:32:13 2007
     Raid Level : raid5
     Array Size : 483363456 (460.97 GiB 494.96 GB)
  Used Dev Size : 241681728 (230.49 GiB 247.48 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 2
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Aug  2 09:22:08 2011
          State : active, degraded, recovering
 Active Devices : 2
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

 Rebuild Status : 0% complete

           UUID : 7e6c101a:09efb900:6ad65a8a:45815ce7
         Events : 0.85765

    Number   Major   Minor   RaidDevice State
       3       8        7        0      spare rebuilding   /dev/sda7
       1       8       23        1      active sync   /dev/sdb7
       2       8       39        2      active sync   /dev/sdc7

# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active raid5 sda7[3] sdb7[1] sdc7[2]
      483363456 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU]
      [>....................]  recovery =  0.0% (39680/241681728) finish=6140.3min speed=653K/sec
      bitmap: 32/231 pages [128KB], 512KB chunk

Avez-vous des solutions, trucs, astuces, etc pour améliorer ce comportement ?

Merci par avance !

  • # changer de disque ou ne pas utiliser la machine pendant la reconstruction

    Posté par  . Évalué à 2.

    si le disque a un defaut, il va falloir plusieurs tentative pour lire/ecrire dessus
    => ca fait monter les I/Owait et donc la charge du processeur (tu le vois dans top)

    cela ralentit donc le processus de reconstruction.

    sinon il semblerait que tu fasses ton RAID sur des partitions (numerotation 7 : sda7/sdb7/sdc7)
    idealement, pour des questions de performances, il ne faudrait pas utiliser les disques sda/sdb/sdc pendant l'operation de reconstruction, car si les tetes bougent pour aller ailleurs (sur sda/sdb/sdc partition 1 à 6) cela genere encore des I/O Waits

    • [^] # Re: changer de disque ou ne pas utiliser la machine pendant la reconstruction

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

      Ha oui, c'est vrai que j'ai pas précisé, au dessus de mon raid, j'ai deux vm (kvm) qui tournent à travers un lvm (les vm font office de serveur web / mail entre autre, donc si je peux les garder en route...)

      Donc si je coupais mes vm et arrêtais un max de service ce serait surement plus rapide ? La différence peut être importante ?

      Question subsidiaire, on peut "monitorer" les IO pour savoir un peu ce que ça donne (pour savoir si la lenteur vient des IO) ?

      • [^] # Re: changer de disque ou ne pas utiliser la machine pendant la reconstruction

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

        Bonjour,

        • pour mesurer les IO : iotop
        • pour mesurer le trafic réseau : iftop
        • pour mesurer l'activité CPU/ram : htop

        Ce sont de très bons utilitaires, dépendant parfois d'un noyau pas trop vieux (je crois que iotop ne tourne pas sur 2.6.26).

        Bon courage
        G

        Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

        • [^] # Re: changer de disque ou ne pas utiliser la machine pendant la reconstruction

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

          Merci pour ces infos, je n'avais jamais utilisé, c'est pas mal du tout (plus sympa que top)

          Par contre, au final je ne comprend rien...
          lorsque je relance la construction du raid (que j'ajoute ma partition manquante) :

          • le load augmente rapidement au dessus de 2 voir 3 (en s'approchant petit à petit de 4)
          • le cpu reste au ralenti... 0.8%us, 1.0%sy, 0.0%ni, 29.3%id, 68.9%wa
          • iotop est au point mort...
            • read 0, write 0
            • lorsqu'il se passe vraiment quelque chose, 7-8 en read, 30 à 50 en write (ko/s hein...)

          Mais les services deviennent inutilisables :(

          Faut-il arrêter tous mes services et démonter tout ce qui est au dessus du raid (démonter les partitions lvm) pour améliorer les choses ?

  • # Brutal

    Posté par  . Évalué à 2.

    Je commencerai par faire une sauvegarde complète. Lors de la reconstruction, les disques travaillent beaucoup, il y a des risques qu'un disque lâche (même si le risque est plus faible que lorsque le problème "raid" est provoqué par un disque qui a lâché).
    Puis les sauvegardes, c'est bien. ;)

    Ensuite, puisque la reconstruction est trèèèèèès lente, je repartirai à zéro et je réintègrerai les données précédemment sauvegardées.

  • # suite

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

    J'ai avancé un peu : j'ai coupé tous les services et démonté les partitions basés sur mon raid5
    J'ai lancé la reconstruction ... et c'est toujours aussi lent :-(

    # cat /proc/mdstat 
    Personalities : [raid1] [raid6] [raid5] [raid4] 
    md2 : active raid5 sda7[3] sdb7[1] sdc7[2]
          483363456 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU]
          [==>..................]  recovery = 11.3% (27313328/241681728) finish=5582.5min speed=638K/sec
          bitmap: 34/231 pages [136KB], 512KB chunk
    

    top me montre qu'il ne fait rien...

    # top
    top - 07:10:06 up 3 days,  9:08,  1 user,  load average: 1.00, 1.03, 1.00
    Tasks: 113 total,   1 running, 112 sleeping,   0 stopped,   0 zombie
    Cpu(s):  0.2%us,  0.7%sy,  0.0%ni, 99.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
    Mem:   3049660k total,   207012k used,  2842648k free,    35524k buffers
    Swap:  2192748k total,        0k used,  2192748k free,   114576k cached
    
      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                           
     1295 root       1 -19     0    0    0 S    1  0.0  22:06.23 md2_raid5                                                                         
     2091 root       1 -19     0    0    0 D    0  0.0   0:24.99 md2_resync
    

    Quelqu'un aurait une autre idée pour accélérer tout ça, disons pour que ça travail un peu quoi, là on à l'impression qu'il ne fait rien du tout...
    Contrairement aux premières tentatives, le wait du proc est toujours inférieur à 3% (des piques entre 2 et 3).

    Merci d'avance !

    • [^] # Re: suite

      Posté par  . Évalué à 2.

      Monitore l'évolution du nombre de secteurs défectueux avec smartmontools?

Suivre le flux des commentaires

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