URL: https://linuxfr.org/forums/linux-debian-ubuntu/posts/debit-ridicule-hd-et-ssd-suite Title: Débit ridicule HD et SSD (suite) Authors: Ytos Date: 2016年11月25日T19:21:51+01:00 License: CC By-SA Tags: debian Score: 3 Salut, J’ai acheté il y a quelques mois une nouvelle carte mère, et depuis j’ai des débits pourris avec le disque dur et le SSD. Version résumée : on dirait que le FS (ext4) torpille son débit au bout de quelques heures/jours d’uptime. Est-ce que quelqu’un a déjà vu ça ? Version détaillée : Juste après le boot, les disques fonctionnent à une vitesse normale. Puis les perfs deviennent dignes de l’usb 1 (sans exagération \^\^ ). Par moment ça revient à la normale dans les jours qui suivent le boot. Mais au bout de quelques jours d’uptime, ça se stabilise sur « débit pourri en permanence ». Et comme je reboot que lorsque c’est nécessaire (la machine fait aussi serveur nfs, etc), ben j’ai des perfs pourries en permanence. Je suis en jessie à jour, avec le noyau 4.6.0-0.bpo.1-686-pae (backports). Le CPU est un i7 6700T, la carte mère est une Asus H170 pro gaming. https://www.asus.com/fr/Motherboards/H170-PRO-GAMING/overview/ J’avais posté un journal en septembre à ce sujet, mais j’ai plusieurs choses à gérer en // donc je n’avais pas fait les tests tout de suite. Ce problème de débit est certes pénible, mais la machine reste utilisable malgré tout. Ceci dit, le jour où ce problème sera réglé, je serais bien content ! :/ Le HD juste après le démarrage : 1048576000 octets (1,0 GB) copiés, 9,93859 s, 106 MB/s Le SSD juste après le démarrage : 1048576000 octets (1,0 GB) copiés, 2,21327 s, 474 MB/s Assez vite après le démarrage, les perfs du SSD sont déjà dégradées, même quand ça beugue pas encore complètement. Le débit est plus faible que ce qu’il devrait être, le SSD se comporte presque comme un HD. 1048576000 octets (1,0 GB) copiés, 6,16263 s, 170 MB/s Mais après que la machine soit restée allumée quelques heures, ça devient n’importe quoi. SSD : 1048576000 octets (1,0 GB) copiés, 625,015 s, 1,7 MB/s HD : 1048576000 octets (1,0 GB) copiés, 618,308 s, 1,7 MB/s (Toutes les valeurs ont été obtenues avec la commande suivante : % dd if=/dev/zero of=test.img bs=1M count=1000) Je pense qu’on avance sur le diagnostic, merci à Benoît Ganne qui m’a dit de tester avec hdparm, et merci aussi à tous ceux qui avaient répondu pour m’aider à avancer. Test du SSD avec hdparm, alors que les perfs sont pourries : ```# for ((i=0;i<5;i++));do hdparm -t /dev/sda ;done Timing buffered disk reads: 1216 MB in 3.00 seconds = 404.71 MB/sec Timing buffered disk reads: 1212 MB in 3.00 seconds = 403.73 MB/sec Timing buffered disk reads: 1214 MB in 3.00 seconds = 404.27 MB/sec Timing buffered disk reads: 1214 MB in 3.00 seconds = 404.26 MB/sec Timing buffered disk reads: 1214 MB in 3.00 seconds = 404.55 MB/sec``` Test du HD : ```# for ((i=0;i<5;i++));do hdparm -t /dev/sdb ;done Timing buffered disk reads: 448 MB in 3.01 seconds = 148.95 MB/sec Timing buffered disk reads: 452 MB in 3.00 seconds = 150.64 MB/sec Timing buffered disk reads: 456 MB in 3.01 seconds = 151.46 MB/sec Timing buffered disk reads: 448 MB in 3.01 seconds = 148.91 MB/sec Timing buffered disk reads: 450 MB in 3.02 seconds = 148.88 MB/sec``` Que ce soit sur le SDD ou sur le HD, une boucle hdparm -T donne des résultats compris entre 10 et 11,5 GB/sec. Donc au niveau matériel, ça semble OK, vachement mieux que mes débits concrets ! Pour info, cette baisse du débit ne touche pas le réseau. Voilà un scp à un moment où les disques rament : 100% 1768MB 84.2MB/s 00:21 Pareil quand j’utilise scp à partir d’une vm virtualbox (située sur le hd) vers /home qui est aussi sur le hd, j’ai des débits raisonnables. Bon, des fois le scp démarre lentement, et je dois le relancer pour avoir le débit raisonnable. J’ai aussi testé avec un livecd fedora, qui a un noyau 4.5 alors que la debian est en 4.6. Donc a priori, le problème ne vient pas d’une version trop vieille du noyau. J’ai mis le livecd un soir avant d’aller pioncer. Le matin suivant, avant de redémarrer sous debian pour bosser, le problème n’était pas apparu. Mais c’est pas très concluant : puisque le problème est aléatoire, un test conséquent avec un autre système demanderait plusieurs jours. Sauf que ça me casserait les pieds d’avoir ma machine bloquée pendant plusieurs jours, sans accès à mon environnement habituel (wm/raccourcis/logiciels configurés/etc). Une info que j’avais oublié de mentionner : le HD est crypté (LUKS), mais pas le SSD. Comme le problème touche les deux, a priori ça innocente LUKS, mais peut-être que je me trompe. Je n’ai pas de processus qui bouffe des I/O (vérifié avec iotop). Le remplissage, donc la fragmentation, est plus que raisonnable : ```% df -h /dev/sda1 202G 18G 184G 9% / /dev/mapper/PARTOCHE 2,5T 1,3T 1,2T 53% /home``` Niveau bios, le SATA est en mode AHCI (la seule autre option c’est RAID, et ça je sais que j’en veux pas). Ensuite il y a 2 options pour chacun des 6 ports SATA disponibles : une option pour désactiver le port, une autre pour spécifier si le port est hotplug ou pas. Les 6 ports sont activés, avec hotplug désactivé. Je pense pas que le bios soit à jour, mais étant donné que les tests plus haut semblent indiquer que le problème serait logiciel plutôt que matériel, je suis pas super chaud pour màj le bios. J’ai un pote qui a briqué sa cm asus comme ça. smartctl et /var/log/dmesg ne semblent pas contenir d’erreurs. Je peux pastebin dmesg, kern.log et syslog si quelqu’un veut y jeter un œil. Voici un aperçu : ```% grep -i sata /var/log/dmesg [ 0.000000] ACPI: SSDT 0x000000008B830018 00036D (v01 SataRe SataTabl 00001000 INTL 20120913) [ 1.819896] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 6 ports 6 Gbps 0x3f impl SATA mode [ 1.865183] ata1: SATA max UDMA/133 abar m2048@0xd124b000 port 0xd124b100 irq 123 [ 1.865379] ata2: SATA max UDMA/133 abar m2048@0xd124b000 port 0xd124b180 irq 123 [ 1.865544] ata3: SATA max UDMA/133 abar m2048@0xd124b000 port 0xd124b200 irq 123 [ 1.865707] ata4: SATA max UDMA/133 abar m2048@0xd124b000 port 0xd124b280 irq 123 [ 1.865871] ata5: SATA max UDMA/133 abar m2048@0xd124b000 port 0xd124b300 irq 123 [ 1.866034] ata6: SATA max UDMA/133 abar m2048@0xd124b000 port 0xd124b380 irq 123 [ 2.175784] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 2.175951] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 2.179649] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.179846] ata5: SATA link down (SStatus 4 SControl 300) [ 2.180176] ata4: SATA link down (SStatus 4 SControl 300) [ 2.351785] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)``` Par ailleurs, depuis que j’ai transféré ce système sur la nouvelle CM, j’ai aussi google chrome qui déconne. L’affichage rame complètement. Voici la liste des paquets venant de backports : dkms firmware-amd-graphics firmware-linux firmware-linux-nonfree firmware-misc-nonfree firmware-realtek linux-base linux-compiler-gcc-4.9-x86 linux-headers-4.6.0-0.bpo.1-686-pae linux-headers-4.6.0-0.bpo.1-common linux-image-4.6.0-0.bpo.1-686-pae linux-kbuild-4.6 linux-libc-dev:i386 virtualbox-dkms xserver-xorg-video-intel

AltStyle によって変換されたページ (->オリジナル) /