À 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 ?
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 ! »
C'est l'écriture dont il parle.
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.
Oui, c’est pour ça que je demande. Ça peut modifier les performances de dd
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 :
[^] # Re: Salut
Posté par Ytos . En réponse au message Débit ridicule HD et SSD (suite). É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