Disque dur malade ? (hdparm, smartctl ...qques précisions)

Pause Café
#1

Salut à tous

J’ai la nette impression d’un ralentissement sur mon serveur (portable vieux de 5 ans, disque dur âgé de 3 ans): losrque je me connecte via ssh, le temps d’avoir la main après avoir tapé le mot de passe est devenu long (3-4 secondes).
J’ai donc regardé les résultats de mon dique dur avec hdparm, et smartctl:

:arrow_right: disque dur du serveur

[code]# hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 114 MB in 2.01 seconds = 56.86 MB/sec
Timing buffered disk reads: 64 MB in 3.02 seconds = 21.21 MB/sec[/code]

# smartctl -a /dev/hda|grep "\(Load_Cycle_Count\|Power_On_Hours\)" 9 Power_On_Hours 0x0012 071 071 000 Old_age Always - 12729 193 Load_Cycle_Count 0x0012 011 011 000 Old_age Always - 897301

Je n’ai aucun critère de comparaison (pas trouvé sur le net, suis preneur de tout lien), mais j’ai un vieux portable de 10 ans (disque dur d’origine), e voici ces résultats:
:arrow_right: disque dur du vieux portable

[code]# hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 222 MB in 2.01 seconds = 110.57 MB/sec
Timing buffered disk reads: 42 MB in 3.00 seconds = 13.98 MB/sec[/code]

# smartctl -a /dev/hda|grep "\(Load_Cycle_Count\|Power_On_Hours\)" 9 Power_On_Hours 0x0032 016 016 050 Old_age Always FAILING_NOW 33867 225 Load_Cycle_Count 0x0032 001 001 070 Old_age Always FAILING_NOW 2309120

Alors déjà un constat: le vieux portable a un disque dur qui n’a pas l’air en bonne santé (FAILING_NOW), et pourtant son disque dur a l’air plus rapide que celui du serveur (temps de lecture du disque: 110.57 MB/sec vs 56.86 MB/sec ).
Quoique le serveur se rattrape sur le temps de lecture du cache: (13.98 MB/sec vs 21.21 MB/sec).
Le temps de parcage des têtes moyen est a peu prés kif: 68 por le vieux, 70 pour le serveur. Pas de différences de ce côté.

En bref:

  • le disque dur du serveur vous inspire-t-il confiance ?
  • pourquoi l’un est plus rapide en lecture sur le disque et moins rapide en lecture sur le cache ?
  • FAILING_NOW veut-il bien dire ce qu’il semble vouloir dire…
    :confused:
#2

Va comprendre Charles…
J’ai redémarré le serveur en forçant la vérif avec fsck (qui n’a rien trouvé d’anormal soit dit en passant…). Et depuis:

[code]# hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 796 MB in 2.00 seconds = 397.69 MB/sec
Timing buffered disk reads: 104 MB in 3.01 seconds = 34.55 MB/sec[/code]
Bref, il est redevenu “rapide” comme avant…En quoi un redémarrage a pu arranger l’histoire ?

#3

Ce n’est ptet pas le redémarrage mais ‘fsck’ qui lui a fait du bien !

#4

Très peu probable.

yanlolot : tu as interverti les débits de lecture cache et lecture disque, et le plus vieux disque est le plus lent, ce qui est logique. 56,86 Mo/s, c’est le débit en lecture cache, pas disque. Et par “cache” il faut comprendre le cache disque en RAM système, pas le cache intégré au disque. Donc ce débit est essentiellement lié à la rapidité de la RAM, et il est mauvais, à peine meilleur que ce que donne la RAM EDO (la techno avant la SDRAM) du Pentium MMX 233 qui me sert de routeur.

Qu’est-ce qui pouvait faire que la mémoire était anormalement lente avant le redémarrage ?
Comme c’est un portable, on peut soupçonner la gestion de fréquence du processeur d’être restée bloquée sur une valeur basse. Ou bien une occupation mémoire qui a provoqué une forte utilisation du swap.

Le disque du vieux portable n’est pas forcément en mauvaise santé, simplement SMART t’avertit qu’il a dépassé sa durée de vie prévue (les attributs montrés sont de type old_age) et qu’il est donc susceptible de mourir de vieillesse.

#5

@Ricardo: il m’est déjà arrivé que fsck doive “réparer” un système de fichier, mais il me le signalait. Or, là, rien de signalé.
@PascalHambourg: Effectivcement, j’ai inversé. Merci pour ton explication. Je n’ai effectivement pas vérifié l’état du swap.
Qt à la gestion du processeur: c’était un portable ( viewtopic.php?f=1&t=28137&start=0&hilit=garantie ), il est dorénavant “fixe”. Je vais regarder ça de plus prêt, afin de régler cette gestion du processeur non plus en tant que portable, mais en tant que pc fixe.

Ce vieux portable (pas le serveur, un autre) a 10 ans et est increvable. Il me sert de boot pxe pour les autres pc au cas où…

Encore merci en tout cas pour ces explications.

#6

Salut

Le pb persiste, mais j’ai qques infos en plus.
Le ralentissement du système apparaît tjs suite à une “grosse opération” (compilation de kernel, téléchargement de plusieurs Go…).
En voici un exemple: je rapatrie 4Go de mon serveur (c’est lui qui déconne) vers mon PC fixe

:arrow_right: avt l’opération de copie d’un grs dossier, sur le serveur:

[code]# hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 810 MB in 2.00 seconds = 404.85 MB/sec
Timing buffered disk reads: 104 MB in 3.00 seconds = 34.63 MB/sec[/code]

# grep MHz /proc/cpuinfo cpu MHz : 2194.657

# free total used free shared buffers cached Mem: 1017636 67928 949708 0 3908 31884 -/+ buffers/cache: 32136 985500 Swap: 257032 0 257032

:arrow_right: J’effectue la copie d’un gros dossier du serveur vers le PC, le tout à partir du PC:

$ scp -r yann@192.168.1.5:"/home/yann/Big\ Dossier" /home/yanlolot/brun_yann/ yann@192.168.1.5's password: video1.avi 100% 351MB 10.3MB/s 00:34 video2.avi 100% 352MB 11.0MB/s 00:32 video3.avi 100% 352MB 11.3MB/s 00:31 video4.avi 100% 348MB 10.9MB/s 00:32 video5.avi 100% 351MB 1.9MB/s 03:07 (...)
A partir de la vidéo 5 (parfois c’est à partir de la 6, ou la 4…), le reste des vidéos est téléchargé à une vitesse d’environs 2MB/s, contre 11MB/s pour les premières vidéos.

:arrow_right: Suite à celà, sur le serveur:

[code]# hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 116 MB in 2.02 seconds = 57.30 MB/sec
Timing buffered disk reads: 72 MB in 3.03 seconds = 23.78 MB/sec[/code]
On remarquera la chute du Timing cached reads.

# free total used free shared buffers cached Mem: 1017636 929956 87680 0 4532 890220 -/+ buffers/cache: 35204 982432 Swap: 257032 0 257032

# grep MHz /proc/cpuinfo cpu MHz : 2194.738

:arrow_right: Différentes remarques:
–> Mon serveur dispose d’un processeur Mobile celeron 2.2GHz (type northwood 256 (13Onm)).
–> Ces tests sont effectués avec pour le serveur un noyau 2.6.32 recompilé pour ce processeur, mais les symptômes restent les mêmes avec un 2.6.30 non recompilé, ou un 2.6.32 non recompilé.
–> 'acpi est activée, et comme c’est un toshiba, le module acpi-toshiba est chargé:

# lsmod |grep toshiba toshiba_acpi 4333 0 rfkill 10118 1 toshiba_acpi
–> Les symptômes restent si je charge le module p4-clockmod (qui correspond à mon processeur), installe cpufreq, et choisi comme governor performance: mon cpu est tjs à 2.2GHz dans ce cas, avt ou après l’opération de transfert de “gros dossier”.
–> Un test de la ram avec Memtest86+ (une seule passe) ne m’indique aucune erreur.
–> j’ai mis à jour le système (squeeze), choisi de mettre les UUID dans le fstab (d’ailleurs depuis mon dd est repéré en /dev/sda, alors qu’avt, il était repéré en /dev/hda…). Reprise de tous les tests (avec différents noyaux, avec ou sans cpufreq…), tjs le même pb.
–> un redémarrage remet tout en ordre.

Quid ? (je penche pour un pb de matos, c’est d’ailleurs pour cela que je poste dans PC)

Merci de votre aide.

#7

Hello,

J’ai lu en diagonale ton fil. Tu peux installer le paquet sysstat qui te fournira des outils d’analyse :

  • iostat : performances disque
  • vmstat : performances mémoire
  • netstat : performances réseau

Exemple d’utilisation : je lance une grosse compile et je veux savoir si mon disque dur est mon facteur limitant, je lance donc en parallère “iostat -x 2” (le 2 siginifie toutes les deux secondes).

Exemple de sortie :

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 16.20 0.00 8.20 0.00 195.20 23.80 0.16 19.44 4.00 3.2

C’est assez pratique pour savoir si l’opération qu’on est en train d’effectuée prends du temps à cause du disque dur.

#8

Merci themorice pour l’info.

Je me suis servi de vmstat (rafraîchi ttes les 2 secondes), et voici sa sortie, avec de précisé, les 3 moments clés:

  • lancement de la copie du “gros dossier” avec scp
  • ralentissement du système
  • arrêt de la copie

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 948452 3860 32316 0 0 1550 50 145 266 6 7 67 20 0 0 0 948444 3860 32324 0 0 0 0 41 9 0 0 100 0 0 0 0 948444 3860 32324 0 0 0 0 41 10 0 0 100 0 0 0 0 947612 3860 32324 0 0 0 0 59 37 2 1 98 0 0 0 0 947644 3860 32328 0 0 0 0 41 8 0 0 100 0 0 0 0 947644 3860 32328 0 0 0 0 41 7 0 0 100 0 0 0 0 926040 3892 47200 0 0 7452 0 4636 1019 20 21 51 9 <-- début copie gros dossier 1 0 0 902996 3916 70232 0 0 11532 0 8499 1655 28 36 34 3 1 0 0 880016 3936 93148 0 0 11466 0 8500 1705 28 33 35 4 1 0 0 856784 3968 116184 0 0 11532 20 8513 1699 29 34 32 5 1 0 0 833828 3992 139096 0 0 11468 0 8486 1643 29 35 31 5 0 0 0 810968 4012 162020 0 0 11466 16 8537 1671 32 33 24 12 1 0 0 787812 4036 185024 0 0 11532 0 8488 1629 31 31 31 7 0 0 0 764712 4056 207964 0 0 11466 0 8485 1738 30 35 33 3 0 0 0 741824 4080 230976 0 0 11532 0 8479 1676 30 33 33 5 2 0 0 718756 4104 253888 0 0 11468 0 8476 1664 30 32 34 4 0 0 0 695536 4124 276932 0 0 11530 0 8493 1722 29 37 31 4 1 0 0 672380 4148 299872 0 0 11468 0 8514 1728 32 36 30 3 1 0 0 649456 4168 322756 0 0 11466 0 8500 1741 29 34 35 4 0 0 0 626376 4192 345820 0 0 11532 0 8488 1605 29 34 34 4 0 0 0 603420 4244 368732 0 0 11470 34 8509 1646 27 37 26 9 1 0 0 580324 4264 391656 0 0 11466 0 8492 1676 31 35 29 6 1 0 0 558084 4292 414108 0 0 11246 0 8623 1594 28 36 29 8 1 0 0 534988 4312 437128 0 0 11530 0 8490 1723 31 33 33 3 1 0 0 512048 4336 460060 0 0 11468 0 8505 1759 30 34 34 3 0 0 0 489028 4360 482948 0 0 11468 0 8479 1726 31 31 34 5 1 0 0 465872 4380 506020 0 0 11530 0 8495 1683 28 36 32 4 1 0 0 443028 4404 528900 0 0 11468 0 8542 1641 26 37 24 13 0 1 0 419884 4428 551940 0 0 11508 0 8495 1664 30 34 31 6 1 0 0 396976 4448 574852 0 0 11490 0 8495 1606 32 34 26 9 1 0 0 374008 4472 597792 0 0 11468 0 8486 1635 29 34 30 8 1 0 0 350768 4492 620836 0 0 11530 0 8487 1704 31 34 31 5 1 0 0 327908 4516 643744 0 0 11468 0 8482 1770 29 36 31 4 2 1 0 304920 4540 666628 0 0 11444 0 8518 1636 31 34 33 3 1 0 0 281824 4560 689696 0 0 11554 0 8515 1739 29 36 31 5 1 0 0 258948 4584 712608 0 0 11468 0 8493 1644 33 32 30 6 1 0 0 235852 4604 735628 0 0 11530 16 8498 1673 29 36 27 9 1 0 0 216296 4636 756760 0 0 10586 0 8166 1577 24 36 32 8 1 0 0 190808 4656 780448 0 0 11850 0 8585 1727 32 36 28 4 0 0 0 167948 4680 803356 0 0 11468 0 8525 1620 29 39 31 2 1 0 0 144868 4704 826424 0 0 11532 0 8487 1660 32 32 32 4 1 1 0 122228 4724 849204 0 0 11402 0 8490 1703 28 35 32 6 1 0 0 113808 4736 862356 0 0 6662 0 4887 952 38 45 14 3 <-- ralentissement de la vitesse de transfert (11MB/s -> 2MB/s) , à partir de là tout le système est ralenti. 1 0 0 109592 4740 866608 0 0 2050 0 968 272 48 52 0 0 1 0 0 105500 4744 870704 0 0 2114 0 988 269 51 49 0 0 1 0 0 101284 4748 874904 0 0 2050 0 970 273 48 52 0 0 1 0 0 97192 4752 879000 0 0 2050 0 973 272 48 52 0 0 1 0 0 93992 4760 882224 0 0 1664 0 788 307 44 56 0 0 1 0 0 90156 4764 886316 0 0 1986 0 958 275 49 51 0 0 1 0 0 86064 4768 890412 0 0 2050 0 977 269 48 52 0 0 1 0 0 81848 4796 894492 0 0 2050 38 981 272 50 50 0 0 1 0 0 77756 4800 898604 0 0 2114 0 979 272 50 50 0 0 1 0 0 73540 4804 902804 0 0 2050 0 976 270 48 52 0 0 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 69448 4808 906900 0 0 2050 0 982 273 48 52 0 0 1 0 0 65356 4812 911024 0 0 2114 0 992 271 47 53 0 0 1 0 0 61140 4816 915224 0 0 2050 0 973 270 48 52 0 0 1 0 0 57172 4820 919216 0 0 1986 0 949 277 52 48 0 0 0 0 0 59020 4820 919720 0 0 256 0 173 55 7 9 84 0 <-- interruption (volontaire ) du téléchargement, l'ordi reste lent. 0 0 0 59020 4820 919720 0 0 0 0 43 9 0 1 99 0 0 0 0 59020 4828 919712 0 0 0 20 45 14 0 0 99 0 0 0 0 59020 4828 919720 0 0 0 0 41 7 0 0 99 0 0 0 0 59020 4828 919720 0 0 0 0 41 6 0 1 99 0 0 0 0 59020 4828 919720 0 0 0 0 41 85 0 0 100 0 0 0 0 59020 4828 919720 0 0 0 0 46 9 0 1 100 0 0 0 0 59020 4828 919720 0 0 0 0 43 15 0 1 99 0

Je remarque:
–> une augmentation constante de la mémoire utilisée dans les buffer et cache (5e et 6e colonne).
–> au moment du ralentissement du système:
- chute brutale du nombre d’interruption matérielles et logicielles (colonne in, 11eme colonne) et du nombre de changement de contexte (de processus) (colonne cs, 12e colonne)
- chute brutale du nombre de blocs lus sur le disque. (colonne bi, 9eme colonne)
–> après l’interruption du téléchargement, rien ne change côté mémoire , côté, io, system et cpu, tout revient à la normale…et pourtant le système est tjs lent.

Conclusion: pour l’apparition du pb, je n’ai pas vraiment d’idée, mais pour sa persistence, ne searit-ce pas un pb de mémoire (ram, car la swap n’intervient pas ) ?

Qu’en pensez-vous ?

[edit 1] cet ordi est muni de deux barettes de ram (2 x 512 Mo), dans le doute :

  • j’en ai enlevé une…tests…idem
  • l’ai changé de slot…tests…idem
  • même procédure avec le deuxième barette…tests…idem
  • finalement, j’ai remis les 2…tests…idem
    [/edit 1]

[edit 2] J’ai désactivé l’APM du DD: hdparm -B 255 /dev/sda … tests…tjs le même pb [/edit 2]

[edit 3]bon, même si je sais (enfin j’ai lu) que vider les caches mémoires ne sert à rien (si ce n’est ralentir le système encore plus), je l’ai fait (tjs dans l’optique de remettre le système dans l’état le plus proche de celui ds lequel il était avt son ralentissement:
–> avt de vider:

# free total used free shared buffers cached Mem: 1017636 919592 98044 0 9556 874812 -/+ buffers/cache: 35224 982412 Swap: 257032 0 257032
–> je vide, vérifie, et test…

[code]# echo 3 > /proc/sys/vm/drop_caches

free

         total       used       free     shared    buffers     cached

Mem: 1017636 45608 972028 0 172 13496
-/+ buffers/cache: 31940 985696
Swap: 257032 0 257032[/code]
Et bah ça n’avance pas: j’ai tjs un temps de lecture sur le disque trés faible…
[/edit 3]

#9

Bon, ça avance un peu, et vous allez rire…
A force de fouiller le net, je suis tombé sur un forum dans lequel qqu’un avait un pb similaire au misn: son disque dur était tjs lent (même pb: le débit en lecure cache était pitoyable). On lui a alors répondu que son pb venait soit de son processeur, soit de sa ram, soit de son north bridge .
Chez moi, j’ai mis hors de cause la ram et le processeur. Il restait donc le north bridge. Je me suis renseigné sur cette bête que je ne connaissais pas. Bref, c’est une puce, et sur les ordis actuelles, elle a svt droit à son radiateur parcequ’elle chauffe…ahhh, ça chauffe ça.
J’ai trouvé la susdite puce sur la carte mère de mon ordi, et effectivement, ça chauffe (vu en y mettant le doigt).
C’est maintenant que vous allez rire: j’ai récupéré un vieux radiateur qui ne me servait plus, l’ai scié, et resoudé pour pouvoir le palcer sur la puce…un peu de bois, qques vis, une vielle règle en fer flexible, de la pâte thermique, et voilà le résultat:

Résultats: le pb que j’avais est tjs là, mais apparaît bcp plus tard (après environs 3 go de téléchargement, alors qu’avt il n’apparaissait qu’après environs 1,5 Go).
Je pense que mon ordi me signale tout doucement qu’il en a marre, qu’il voudrait pouvoir profiter d’une retraire bien méritée, mais comme c’est une machine, sa retraite, il peut se la mettre ou je pense.
J’envisage de plus en plus l’achat d’un fitpc…mais tant qu’il tient…

#10

Bravo,
Beau bricolage! :038
Et avec un radiateur de 4L tu gagnerais encore, non ? :mrgreen: :wink:

#11

:laughing:
Non, mais je cherche un radiateur plus gros (récup pas achat, vu l’état de l’ordi), mais il faut pouvoir le fixer. Pour le gros radiateur rose sur le cpu, il y avait un emplacement prévu sur la carte mère pour visser le rad, mais pour le north bridge, il n’y en a pas. Donc, pas facile d’adapter.
J’aimerais aussi pouvoir extraire le disque dur: touver un cable mâle-femelle qui correspond au dd de portable (entrée IDE 2,5", et sortie IDE 2,5"). On trouve facilement un cable pour venir brancher un dd de portable sur une tour, mais je n’en trouve qui permette de brancher le dd du portable tjs sur le portable, mais plus loin grâce à ce cable.
Ça me débloquerait la situation: gain de place, et possibilité de se débarraser de la coque plastique pour ne garder que la carte mère, et le dd.
Si quelqu’un connaît une adresse pour ce genre de cable, je suis preneur.