Le 28-09-2009, à 22:51:12 +0200, Jean-Yves F. Barbier (12ukwn@gmail.com) a écrit :
> steve a écrit :
> ...
> > Attends, là tu parles de la debian toute fraîche ou le système que
> > j'essaie de réparer ? Car ya pu de debian toute fraîche, j'ai utilisé le
>
> hou, c'est embrouillé tout ça!
mais noooooooooooooon :-)
> là, tu veux dire quoi exactement, que tu a remis le couvert avec ton vieux système?
Exact. J'ai fait le test d'installer une lenny toute fraîche, test qui a
été concluant (pas de problème hardware), et ensuite j'ai utilisé ce HD
pour recréer un raid sur le vieux système (pas sûr qu'il apprécierait
que l'on parle de lui en ces termes).
> > disque pour refaire le raid 1. Ce qui est fait d'ailleurs et en gros ça
> > n'a pas changé grand chose, les lenteurs persistent lors de la copie de
> > données d'un DVD (un fichier de 600Mb). J'ai fait des tests avec le
>
> en fonction du lecteur, l'extraction dvd peut prendre du temps
c'est pas vraiment la durée qui m'ennuie, mais plutôt le fait que le
système soit gelé pendant cette opération. L'extraction (enfin la copie)
se fait a un rythme de 4.5 Mo/s, j'arrive pas savoir si c'est lent ou
rapide.
> essaye
> plutôt une extraction à partir d'un CD, c'est plus significatif.
Cd musique ?
> > second lecteur dvd, même problème. Ensuite j'ai physiquement débranché
> > le lecteur DVD le plus lent et refait des tests, et là il semblait que
> > ça allait mais sans être parfait car après 10-15 secondes, le système se
> > figeait jusqu'à la fin de la copie. Ensuite, j'ai redémarré sur un
>
> ça ressemble à un PB d'IRQ trop sollicités
Ahhh, une idée !! Et la solution pour l'alléger serait quoi ?
> > ancien noyau (2.6.26) et refait les tests. Comme avant. Et juste avant
>
> comme avant quoi?? => ça refonctionne correctement avec le 2.6.26 ou pas?
Nan. Aucune de mes tests n'ont montré un fonctionnent normal.
> > de répondre à ce message, je me suis logué sous gnome, puis fluxbox en
> > pensant que c'était peut-être kde qui faisait des siennes, et bingo,
> > toujours pareil.
>
> je ne pense pas que ça vienne d'une couche haute du système.
Bon, toujours est-il qu'on sait que ce n'est pas un wm particulier qui
fout le boxon.
> ...
> > Alors au niveau HD, y a-t-il des marques particulièrement sans surprise
> > pour des systèmes GNU/Linux ?
>
> la perfection n'est pas de ce monde...
> disons que Seagate a rarement eu de mauvais moments dans son histoire,
> mais comme pour toutes les marques, c'est cyclique.
Bon, c'est un des deux en marche actuellement. Je vais essayer de mettre
en fail l'autre patte du raid 1 (donc pas le seagate, le WD), et voir ce
qui se passe. J'ai refait un test hdparm, et on voit une grosse
différence :
# hdparm -tT /dev/sda /dev/sdb
/dev/sda:
Timing cached reads: 14374 MB in 1.99 seconds = 7205.39 MB/sec
Timing buffered disk reads: 180 MB in 3.02 seconds = 59.61 MB/sec
/dev/sdb:
Timing cached reads: 15108 MB in 1.99 seconds = 7575.51 MB/sec
Timing buffered disk reads: 354 MB in 3.01 seconds = 117.59 MB/sec
La seconde valeur est deux fois plus élevée sur sdb que sur sda. Est-ce
que ça pourrait freiner l'écriture sur sdb et provoquer ces lenteurs ?
> je ne crois pas trop que ça vienne du HD; qu'est ce que disent:
> cat /proc/interrupts & lspci -v ?
cat /proc/interrupts
CPU0 CPU1
0: 1410302 1396449 IO-APIC-edge timer
1: 0 2 IO-APIC-edge i8042
4: 1 1 IO-APIC-edge
8: 1 0 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
12: 2 2 IO-APIC-edge i8042
16: 41362 41411 IO-APIC-fasteoi uhci_hcd:usb2, pata_marvell, EMU10K1
17: 157115 157729 IO-APIC-fasteoi firewire_ohci, HDA Intel, eth1
18: 1137188 1150614 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8, wifi0
19: 454 442 IO-APIC-fasteoi uhci_hcd:usb7, firewire_ohci
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb4
22: 23408 23148 IO-APIC-fasteoi HDA Intel
23: 34 36 IO-APIC-fasteoi ehci_hcd:usb3, uhci_hcd:usb6
28: 261932 258850 PCI-MSI-edge ahci
29: 1 0 PCI-MSI-edge eth0
NMI: 0 0 Non-maskable interrupts
LOC: 842517 899466 Local timer interrupts
SPU: 0 0 Spurious interrupts
RES: 293142 268206 Rescheduling interrupts
CAL: 881 958 Function call interrupts
TLB: 4660 3344 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
ERR: 0
MIS: 0
et pour le lspci -v, voir en attaché.
Attachment:
lspci-v.txt.bz2
Description: Binary data