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
# Salut
Posté par Marotte ⛧ . Évalué à 2.
À part l’affichage (qui serait à priori un autre problème) tu as concrètement des problèmes de lenteur quand ça écrit ou lit sur le disque ?
Si tu fais un "sync", ça rame ?
1M c’est la taille exacte des blocs ?
[^] # Re: Salut
Posté par Tanouky . Évalué à 2. Dernière modification le 26 novembre 2016 à 10:24.
C'est l'écriture dont il parle.
hdparm donne des indications de lecture "normale".
1M, c'est la taille des blocs lors d'une écriture avec dd, il semblerait.
[^] # Re: Salut
Posté par Marotte ⛧ . Évalué à 2.
Oui, c’est pour ça que je demande. Ça peut modifier les performances de dd. Il y a une taille de bloc optimal qui correspond généralement à N×taille de bloc du device… Cela dit, de là à ce que ça influe autant j’ai un doute, je disais ça comme ça.
[^] # Re: Salut
Posté par Ytos . Évalué à 2. Dernière modification le 27 novembre 2016 à 14:15.
Yep, je poste un journal parce que l’utilisation de tous les jours est assez pénible, les performances des trucs habituels (copie de fichiers, etc) sont à la ramasse.
Je suis pas un fana de perfs, et si j’ai dégaîné dd c’était pour objectiver mon impression. Quand j’ai vu le résultat, je me suis dit « ah ben tu m’étonnes que ça rame, forcement ! »
Tiens tiens, je n’avais pas percuté que le problème se posait uniquement en écriture. Si j’ai moins de problèmes quand j’utilise scp, c’est pas une question de réseau, c’est parce que je l’utilise 99% du temps en lecture (de ma machine de bureau vers une autre).
Comme les deux disques (SSD et HD) sont touchés par ce problème de débits en écriture, un test de lecture sur un disque sera forcement bridé par l’écriture sur l’autre disque.
Et donc, en réseau on retrouve le problème en écriture :
Du coup, ça relance la piste du problème matériel, que je pensais écartée avec le test hdparm.
Je suis pas spécialiste du matos et des couches basses, mais il me semble que les applications ne sont pas concernées par les tailles de blocs ou secteurs. Si les options de dd pouvaient fausser le diagnostic, ça veut dire que cp, mv et autres coreutils comploteraient pour sélectionner une mauvaise taille de blocs/secteurs. Idem pour firefox, qui rame comme une loutre bourrée par moment. J’imagine que c’est lorsqu’il a besoin de faire plein d’écritures sur sa base sqlite.
J’ai des perfs pourries à l’utilisation et c’est ça mon problème, je ne cherche pas à optimiser un test pour que dd m’affiche la plus grosse valeur possible avec mon matériel ;-)
Sinon on m’avait posé une question sur la taille des blocs sur un journal précédent, voici les tests que j’avais fait :
https://linuxfr.org/nodes/109175/comments/1665759
# surchauffe?
Posté par EauFroide . Évalué à 1.
T'as pas un élément de ta machine qui surchauffe?
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: surchauffe?
Posté par Ytos . Évalué à 1.
A priori, non :
De plus, quand je place la main devant le ventilo de l’alim, l’air n’est pas chaud.
# Idée...
Posté par Tanouky . Évalué à 2.
Ne tester qu'un disque pendant plusieurs jours, puis l'autre ?
Je sais que tu ne veux pas te séparer de ta machine plusieurs jours, mais c'est peut-être un bon compromis ?
[^] # Re: Idée...
Posté par Ytos . Évalué à 1.
Je ne suis pas spécialiste en matos, mais ça me semble peu probable que deux disques créent un problème de débit en écriture, juste parce qu’ils seraient incompatibles entre eux ? En SATA, chaque disque a sa propre nappe…
J’ai / sur le SSD et /home sur le HD. J’ai pas la place de copier /home sur le SSD, et le HD est en LUKS+LVM, et je préfère éviter de rajouter LUKS dans ma séquence de boot (et par le passé, grub m’a déjà embêté avec LVM).
De plus, même si j’étais pas frileux, repartionner le LVM et tout configurer pour booter en LUKS, lire la doc, tout bien tester, etc me demandera sans doute autant de temps qu’installer une autre distrib et faire des tests de copie en boucle. À la limite le 2ème cas me demanderait moins de temps, en fait : dans les deux cas, l’ordi serait pas dispo mais dans le 2ème cas je pourrais faire autre chose, à condition que ça soit pas sur l’ordi. Sauf que pour bosser, j’ai besoin de l’ordi.
[^] # Re: Idée...
Posté par NeoX . Évalué à 2.
ton probleme ne viendrait-il pas de LUKS+LVM ?
la lecture est rapide parce que les données sont dechiffrées quand tu rentres dans le dossier
l'ecriture est plus lente parce qu'il faut recevoir les données, les cryptées puis les stocker (ou les stocker puis crypter les blocs selon ou se trouve le cryptage)
si tu as du LVM, essaie de faire une partition en dehors de LUKS
et regarde si tu as toujours tes lenteurs quand tu ecris sur cette nouvelle partition.
[^] # Re: Idée...
Posté par Ytos . Évalué à 1.
Seule /home, sur le HD, est en LUKS. / est sur le SSD sans LUKS, et y’a aussi le problème de débit.
Qu’est-ce que tu entends par « les données sont dechiffrées quand tu rentres dans le dossier » ? J’ai pas suivi ta démonstration, je vois pas pourquoi décrypter serait plus rapide que crypter.
La config recommandée c’est LUKS+LVM plutôt que LVM+LUKS, et c’est ce que j’ai fait. Donc j’ai un volume LUKS sur tout le HD.
Mais comme dit plus haut, sans LUKS et sur un autre disque, ça rame pareil.
# BIOS / x86-64
Posté par WhiteCat . Évalué à 4.
C'est pourtant bien une chose extrêmement importante à faire dans ton cas. Si ça se trouve le BIOS corrige un bug errata du chipset… comment savoir, les changelogs ASUS sont complètement bidons.
Je suis partisan de mettre à jour son BIOS quand il y a une mise à jour (sauf si le changelog est suffisamment explicite pour voir que cela n'est pas pertinent bien sûr).
À moins d'avoir une coupure électrique pendant les 2 minutes que dure le flash (grosso modo), c'est difficile de bousiller sa carte mère en mettant à jour son BIOS. Je me demande comment ton pote s'y est pris. Depuis des années j'ai mis à jour plusieurs dizaines de BIOS, de façon bien différente sans problème (màj via utilitaire Windows, via utilitaire DOS, via le BIOS + clé USB, via l'utilitaire flahsrom sur Linux sur des cartes mères déjà testées ou non, sur Linux avec les utilitaires HP et IBM pour serveurs, etc.).
Assures-toi juste de prendre une clé USB FAT32 que tu estimes fiable, copie ton BIOS dessus, fais un checksum du BIOS sur ton HDD et sur ta clé pour vérifier qu'elle est bien copiée dessus.
Tu as une raison particulière de fonctionner en 32 bits ?
En 32 ou 64 bits ?
[^] # Re: BIOS / x86-64
Posté par Tanouky . Évalué à 1.
À noter qu'il a tout de même changé de carte mère.
[^] # Re: BIOS / x86-64
Posté par flavien75 . Évalué à 1.
en même temps, plus c'est neuf, plus il y a de chances que ce soit buggé.
+1 pour la mise à jours du BIOS
Les vrais naviguent en -42
[^] # Re: BIOS / x86-64
Posté par Ytos . Évalué à 1.
Renseignements pris, c’était une Gigabyte pas une Asus, et il s’agissait d’une série semi-pro mal testée et peu vendue. Mais par contre, aux débuts des amd64, c’était bien avec Asus qu’il y a eu plein de problèmes.
Ce qui me refroidit, c’est que lorsqu’on a une merde logicielle on tire la sauvegarde. Quand on a une panne matos, soit on renvoit en SAV (donc indisponibilité d’une semaine au grand minimum), soit on jette et on remplace, et il faut attendre que le nouveau matos arrive, le monter, le tester, etc.
Certes, on peut faire de la récup pour avoir des pièces détachées, ou être à l’affut des bons plans pour avoir du spare sous la main, voir même tout acheter en double. Mais dans tous les cas, ça demande du temps et/ou de l’argent… Ça se sent que j’aime pas le matos et que je préfère la partie logicielle ? :)
Avec le test hdparm et le fait que le réseau semblait pas touché, je pensais que le problème était logiciel (du genre bug dans le VFS, ou un truc comme ça), pas matériel. Du coup, l’intérêt de flasher le bios me semblait limité.
Sauf qu’en fait, tout ce que le test hdparm et le réseau montrent, c’est que le problème se pose uniquement à l’écriture (voir mon commentaire plus haut). Donc, ça pourrait venir du matos, finalement.
Ouais, j’étais déjà allé sur leur site pour voir si le changelog d’une màj bios comportait une mention qui évoquait mon problème. J’ai pu constater à quel point c’est laconique, on a que 2 types de màj : « Improve system stability » ou « Support new CPUs ». Paye tes détails…
https://www.asus.com/Motherboards/H170-PRO-GAMING/HelpDesk_Download/
Et je suis partisan de pas réparer ce qui marche :)
Mais là, ça ne marche pas. Donc, à moins que quelqu’un ait une autre idée, je vais monter une machine de secours au cas où, et je vais tenter la màj du bios. Je vous tiendrais au courant quand ça sera fait. Ici en commentaire si ça marche ; avec un nouveau journal si ça continue à déconner, pour récolter de nouveaux avis.
J’ai installé le système de ma machine perso il y a (très) longtemps, et depuis je l’ai dist-upgradé. Avant l’époque de puppet, je m’embêtais à réinstaller et tout reconfigurer pour d’autres machines. D’une part, après une réinstall, pendant plusieurs semaines je tombais en permanence sur des paquets que j’avais oublié d’installer ou de personnaliser sur le nouveau système. D’autre part, j’ai constaté que lorsque j’avais des bugs sur ma machine perso (qui avait été dist-upgradée au lieu d’être réinstallée), je retrouvais exactement les mêmes bugs sur les systèmes "neufs". Conclusion, je vois pas l’intérêt de passer du temps à installer des paquets manuellement et refaire les configs, si on obtient le même état en faisant dist-upgrade.
Depuis, pour le premier point, de nos jours y’a puppet et compagnie. Sauf que sur ma machine de bureau, j’ai pas mal de trucs personnalisés (et non, tout ce qui est personnalisé n’est pas nécessairement dans ~) et beaucoup ne sont pas dans puppet : à commencer par tout ce qui n’est que sur cette machine de bureau.
Il faudra que je passe en 64 bits un jour, mais pour l’instant avec le PAE, les avantages du 64 bits me semblent pas justifier le temps que ça prendrait de tout reconfigurer sur ma machine perso.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.