J'utilise Debian depuis une quinzaine d'années, sans problème de RAID
jusqu'à présent. Mon souci actuel est que deux machines qui font chacune
du RAID1 sur deux disques SSD ont des performances disque qui se dégradent
brutalement, sans raison apparente (rien trouvé dans syslog, notamment).
La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La
différence est si nette qu'une mesure grossière avec 'dd' suffit à la
mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=10000).
* La machine à la maison en a été la première victime, dès son
installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée en
janvier aussi). Le PC était neuf, ses disques aussi. (C'est toujours la
version stable de Debian que j'utilise.)
* La machine de bureau, qui donnait entière satisfaction depuis plusieurs
années, a commencé à montrer les mêmes symptômes juste après son passage de
Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce n'était pas
une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8 n'était que
partiellement à jour car j'utilise apt-get upgrade mais jamais dist-upgrade. La
version de Debian 8 sur la machine à la maison en janvier 2017 était donc en un
sens plus récente que la version de Debian 8 sur la machine de bureau en
juillet 2017.
* Par ailleurs, j'ai passé deux autres machines en Debian 9 sans rencontrer le
problème, mais elles font toutes deux du RAID6 sur des disques à plateaux.
* Les quatre machines utilisent exclusivement JFS.
Je souligne que même quand les performances deviennent abyssales, les tableaux
RAID fonctionnent. On peut par exemple copier un fichier ('cp').
Redémarrer la machine restaure la performance normale. La performance reste
alors stable pendant plusieurs heures. Puis elle s'écroule, ce qui peut
arriver même quand il n'y a personne devant l'écran, en pleine nuit.
Je joins ci-dessous le résultat des commandes suivantes, lancées sur la machine
de bureau (RAID1 sur sda+sdb):
smartctl -t short /dev/sda
smartctl -l selftest /dev/sda
smartctl -t short /dev/sdb
smartctl -l selftest /dev/sdb
Est-ce que ces comportements vous évoquent des souvenirs, ou des pistes à
creuser ? Comment pourrais-je extraire du système des informations sur
l'origine du problème ? Voyez-vous quels changements intervenus dans la
Debian 8, après la release initiale, pourraient causer ce comportement ?
Merci d'avance pour votre aide !
Seb.
PS: si quelqu'un sait comment régler le p'tit problème suivant, ça me sera
utile aussi: jusqu'à la Debian 8 incluse, quand je faisais un copier-coller
d'une ligne entière depuis un xterm vers un xterm exécutant zsh, la commande
s'exécutait dès l'étape coller. Depuis le passage à Debian 9, la commande
collée apparaît en inverse vidéo, un retour à la ligne a bien été inséré (le
curseur est sur une nouvelle ligne), mais cela ne provoque pas l'exécution de
la commande, il faut encore que j'appuie sur Entrée. J'aimerais bien revenir à
la situation précédente (pas besoin d'appuyer sur Entrée) mais je ne sais pas
ce qu'il faut régler...
#smartctl -l selftest /dev/sda
smartctl 6.6 2016-05-31 r4324 [i686-linux-4.9.0-3-686-pae] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours)
LBA_of_first_error
# 1 Short offline Completed without error 00% 17786 -
# 2 Short offline Completed without error 00% 15666 -
#smartctl -l selftest /dev/sdb
smartctl 6.6 2016-05-31 r4324 [i686-linux-4.9.0-3-686-pae] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours)
LBA_of_first_error
# 1 Short offline Completed without error 00% 16593 -
J'ai également constaté un comportement très similaire sur un de mes serveurs après le passage a debian9.
Merci de le dire !
J'ai également incriminé le raid (raid5 hard HP).
Sur disques SSD ou à plateaux ? Avec quel filesystem ?
A plateaux, ext4 -- Cordialement Jean-Bernard Dubois Gaïa Converter
BERTRAND Jo=c3=abl
Jean-Bernard Dubois a écrit :
Le 27/09/2017 à 13:00, Seb a écrit :
Bonjour,
J'ai également constaté un comportement très similaire sur un de mes serveurs après le passage a debian9.
Merci de le dire !
J'ai également incriminé le raid (raid5 hard HP).
Sur disques SSD ou à plateaux ? Avec quel filesystem ?
A plateaux, ext4
Bonjour, Avec Buster, je ne note pas ce genre de désagrément. ext3 et ext4 sur raid1 et rai6d tout en magnétique (machine avec un i7 et 16 Go de mémoire). Noyau courant : 4.12.0-1-amd64 En revanche, sur un portable avec 4Go de mémoire (et un core2duo), j'ai régulièrement avec ce même noyau le passage de oom-killer, ce que je n'avais jamais avant lui. Je pense qu'il y a un problème plus général qu'un problème raid avec ce noyau. Cordialement, JKB
Jean-Bernard Dubois a écrit :
Le 27/09/2017 à 13:00, Seb a écrit :
Bonjour,
J'ai également constaté un comportement très similaire sur un de mes
serveurs après le passage a debian9.
Merci de le dire !
J'ai également incriminé le raid (raid5 hard HP).
Sur disques SSD ou à plateaux ?
Avec quel filesystem ?
A plateaux, ext4
Bonjour,
Avec Buster, je ne note pas ce genre de désagrément. ext3 et ext4 sur
raid1 et rai6d tout en magnétique (machine avec un i7 et 16 Go de mémoire).
Noyau courant : 4.12.0-1-amd64
En revanche, sur un portable avec 4Go de mémoire (et un core2duo), j'ai
régulièrement avec ce même noyau le passage de oom-killer, ce que je
n'avais jamais avant lui. Je pense qu'il y a un problème plus général
qu'un problème raid avec ce noyau.
J'ai également constaté un comportement très similaire sur un de mes serveurs après le passage a debian9.
Merci de le dire !
J'ai également incriminé le raid (raid5 hard HP).
Sur disques SSD ou à plateaux ? Avec quel filesystem ?
A plateaux, ext4
Bonjour, Avec Buster, je ne note pas ce genre de désagrément. ext3 et ext4 sur raid1 et rai6d tout en magnétique (machine avec un i7 et 16 Go de mémoire). Noyau courant : 4.12.0-1-amd64 En revanche, sur un portable avec 4Go de mémoire (et un core2duo), j'ai régulièrement avec ce même noyau le passage de oom-killer, ce que je n'avais jamais avant lui. Je pense qu'il y a un problème plus général qu'un problème raid avec ce noyau. Cordialement, JKB
Thierry Bugier
Bonjour Le jeudi 28 septembre 2017 à 08:59 +0200, Jean-Bernard Dubois a écrit :
Le 26/09/2017 à 16:40, Thierry Bugier a écrit :
Bonjour Le mardi 26 septembre 2017 à 15:55 +0200, Jean-Bernard Dubois a écrit : > J'ai également constaté un comportement très similaire sur un de > mes > serveurs après le passage a debian9. J'ai également incriminé le > raid > (raid5 hard HP). > Mais après plusieurs essais, je constate que le même phénomène se > produit aussi sur le disque amovible USB3 qui est sur la même > machine. Sur ce type de RAID, j'imagine que ce sont des disques magnétiques, n'est ce pas ?
Oui. Et le disque amovible est aussi a plateaux et pas du tout en raid.
Donc c'est clair (et d'autres messages le confirment) que ce n'est pas lié à la nature des disques. Je n'ai pas pu réfléchir encore aux graphes de performance délivrés hier. Peut être ce soir. Si un disque en USB3 (non RAID) pose également le souci je crois que le code du RAID logiciel n'est pas en cause, et que ça se passe ailleurs. Vu la solution de contournement, ca doit se passer au niveau de la gestion du cache en RAM.
Bonjour
Le jeudi 28 septembre 2017 à 08:59 +0200, Jean-Bernard Dubois a écrit :
Le 26/09/2017 à 16:40, Thierry Bugier a écrit :
> Bonjour
>
> Le mardi 26 septembre 2017 à 15:55 +0200, Jean-Bernard Dubois a
> écrit :
> > J'ai également constaté un comportement très similaire sur un de
> > mes
> > serveurs après le passage a debian9. J'ai également incriminé le
> > raid
> > (raid5 hard HP).
> > Mais après plusieurs essais, je constate que le même phénomène se
> > produit aussi sur le disque amovible USB3 qui est sur la même
> > machine.
>
> Sur ce type de RAID, j'imagine que ce sont des disques magnétiques,
> n'est ce pas ?
>
>
Oui. Et le disque amovible est aussi a plateaux et pas du tout en
raid.
Donc c'est clair (et d'autres messages le confirment) que ce n'est pas
lié à la nature des disques.
Je n'ai pas pu réfléchir encore aux graphes de performance délivrés
hier. Peut être ce soir.
Si un disque en USB3 (non RAID) pose également le souci je crois que le
code du RAID logiciel n'est pas en cause, et que ça se passe ailleurs.
Vu la solution de contournement, ca doit se passer au niveau de la
gestion du cache en RAM.
Bonjour Le jeudi 28 septembre 2017 à 08:59 +0200, Jean-Bernard Dubois a écrit :
Le 26/09/2017 à 16:40, Thierry Bugier a écrit :
Bonjour Le mardi 26 septembre 2017 à 15:55 +0200, Jean-Bernard Dubois a écrit : > J'ai également constaté un comportement très similaire sur un de > mes > serveurs après le passage a debian9. J'ai également incriminé le > raid > (raid5 hard HP). > Mais après plusieurs essais, je constate que le même phénomène se > produit aussi sur le disque amovible USB3 qui est sur la même > machine. Sur ce type de RAID, j'imagine que ce sont des disques magnétiques, n'est ce pas ?
Oui. Et le disque amovible est aussi a plateaux et pas du tout en raid.
Donc c'est clair (et d'autres messages le confirment) que ce n'est pas lié à la nature des disques. Je n'ai pas pu réfléchir encore aux graphes de performance délivrés hier. Peut être ce soir. Si un disque en USB3 (non RAID) pose également le souci je crois que le code du RAID logiciel n'est pas en cause, et que ça se passe ailleurs. Vu la solution de contournement, ca doit se passer au niveau de la gestion du cache en RAM.
Seb
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1390703288-1506612373=:20418 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: Bonjour,
Donc c'est clair (et d'autres messages le confirment) que ce n'est pas lié à la nature des disques.
(Ni au système de fichiers.)
Vu la solution de contournement, ca doit se passer au niveau de la gestion du cache en RAM.
Ça semble sensé. Je viens d'installer un noyau 4.12 (686-pae) avec stretch-backport, on verra si cela change quelque chose... Seb. ---1155178722-1390703288-1506612373=:20418--
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1390703288-1506612373=:20418 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: Bonjour,
Donc c'est clair (et d'autres messages le confirment) que ce n'est pas lié à la nature des disques.
(Ni au système de fichiers.)
Vu la solution de contournement, ca doit se passer au niveau de la gestion du cache en RAM.
Ça semble sensé. Je viens d'installer un noyau 4.12 (686-pae) avec stretch-backport, on verra si cela change quelque chose... Seb. ---1155178722-1390703288-1506612373=:20418--
Seb
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1770687665-1506613579=:20418 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Bonjour Pascal,
Plus exactement, la valeur 2 ne vide que les caches de "dentries" (directory entries) et d'inodes, c'est-à-dire les méta-données associées aux répertoires et fichiers, mais pas le cache du contenu des fichiers.
Merci pour la correction.
L'information m'a peut-être échappée, mais je n'ai pas vu dans les messages si des tests de débit comparatifs pour déterminer l'étendue précise du problème avaient été faits : - en lecture dans le système de fichiers
Non testé.
- en écriture dans le système de fichiers
Testé.
- en lecture brute dans le périphérique bloc - en écriture brute dans le périphérique bloc (attention : détruit le système de fichiers)
Pas testé :-)
- même chose dans une partition classique non RAID
Testé en écriture (pas par moi): pareil.
- même chose avec d'autres types de systèmes de fichiers
Non testé. Quelles informations rechercherait-on avec ces tests supplémentaires ? Seb. ---1155178722-1770687665-1506613579=:20418--
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Plus exactement, la valeur 2 ne vide que les caches de "dentries"
(directory entries) et d'inodes, c'est-à-dire les méta-données associées
aux répertoires et fichiers, mais pas le cache du contenu des fichiers.
Merci pour la correction.
L'information m'a peut-être échappée, mais je n'ai pas vu dans les messages
si des tests de débit comparatifs pour déterminer l'étendue précise du
problème avaient été faits :
- en lecture dans le système de fichiers
Non testé.
- en écriture dans le système de fichiers
Testé.
- en lecture brute dans le périphérique bloc
- en écriture brute dans le périphérique bloc (attention : détruit le système
de fichiers)
Pas testé :-)
- même chose dans une partition classique non RAID
Testé en écriture (pas par moi): pareil.
- même chose avec d'autres types de systèmes de fichiers
Non testé.
Quelles informations rechercherait-on avec ces tests supplémentaires ?
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1770687665-1506613579=:20418 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Bonjour Pascal,
Plus exactement, la valeur 2 ne vide que les caches de "dentries" (directory entries) et d'inodes, c'est-à-dire les méta-données associées aux répertoires et fichiers, mais pas le cache du contenu des fichiers.
Merci pour la correction.
L'information m'a peut-être échappée, mais je n'ai pas vu dans les messages si des tests de débit comparatifs pour déterminer l'étendue précise du problème avaient été faits : - en lecture dans le système de fichiers
Non testé.
- en écriture dans le système de fichiers
Testé.
- en lecture brute dans le périphérique bloc - en écriture brute dans le périphérique bloc (attention : détruit le système de fichiers)
Pas testé :-)
- même chose dans une partition classique non RAID
Testé en écriture (pas par moi): pareil.
- même chose avec d'autres types de systèmes de fichiers
Non testé. Quelles informations rechercherait-on avec ces tests supplémentaires ? Seb. ---1155178722-1770687665-1506613579=:20418--
Pascal Hambourg
Le 28/09/2017 à 17:46, Seb a écrit :
si des tests de débit comparatifs pour déterminer l'étendue précise du problème avaient été faits : - en lecture dans le système de fichiers
Non testé.
- en écriture dans le système de fichiers
Testé.
- en lecture brute dans le périphérique bloc - en écriture brute dans le périphérique bloc (attention : détruit le système de fichiers)
Pas testé :-)
- même chose dans une partition classique non RAID
Testé en écriture (pas par moi): pareil.
- même chose avec d'autres types de systèmes de fichiers
Non testé. Quelles informations rechercherait-on avec ces tests supplémentaires ?
Déterminer quels sont les facteurs qui impactent les performances.
Le 28/09/2017 à 17:46, Seb a écrit :
si des tests de débit comparatifs pour déterminer l'étendue
précise du problème avaient été faits :
- en lecture dans le système de fichiers
Non testé.
- en écriture dans le système de fichiers
Testé.
- en lecture brute dans le périphérique bloc
- en écriture brute dans le périphérique bloc (attention : détruit le
système de fichiers)
Pas testé :-)
- même chose dans une partition classique non RAID
Testé en écriture (pas par moi): pareil.
- même chose avec d'autres types de systèmes de fichiers
Non testé.
Quelles informations rechercherait-on avec ces tests supplémentaires ?
Déterminer quels sont les facteurs qui impactent les performances.
si des tests de débit comparatifs pour déterminer l'étendue précise du problème avaient été faits : - en lecture dans le système de fichiers
Non testé.
- en écriture dans le système de fichiers
Testé.
- en lecture brute dans le périphérique bloc - en écriture brute dans le périphérique bloc (attention : détruit le système de fichiers)
Pas testé :-)
- même chose dans une partition classique non RAID
Testé en écriture (pas par moi): pareil.
- même chose avec d'autres types de systèmes de fichiers
Non testé. Quelles informations rechercherait-on avec ces tests supplémentaires ?
Déterminer quels sont les facteurs qui impactent les performances.
Seb
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-623620097-1507143937=:14487 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: Bonjour,
Pour finir, je sais obtenir un retour a des performances normales en vidant le cache : sync ; echo 2 > /proc/sys/vm/drop_caches et comme toi, j'ai une nouvelle dégradation violente au bout d'un certain temps.
Il y a quelques jours, j'ai passé la machine à la maison (Debian 9 stable) sur le noyau 4.12.0-0.bpo.1-686-pae (backports). J'ai continué à mesurer la performance des disques avec cette nouvelle situation. Voici le résultat: https://framapic.org/bFa8E3Zz3aJA/3vFMDsmo5LhF.png J'observe ceci: * La vitesse normale de la partition mesurée (par un simple 'dd') est d'environ 1000 Mo/s. Cette vitesse est atteinte si j'appelle à la main la commande envoyée par Jean-Bernard: sync; echo 2 >! /proc/sys/vm/drop_caches * Le système n'est toujours pas stable à cette vitesse, mais quand le débit chute, après quelques heures seulement, il peut se stabiliser vers 150 Mo/s (1er octobre) ou (comme avant) à < 1 Mo/s (4 octobre). La chute est toujours aussi brutale. * Au régime intermédiaire 150 Mo/s, le système finit par retomber spontanément au régime bas < 1 Mo/s. * Dans les minutes qui suivent minuit, auparavant quelque chose dans le système (dans le noyau ?) envoyait la machine en régime bas; maintenant, cette même chose la remet en régime intermédiaire si elle se trouvait en régime bas (2-3 octobre) mais aussi si elle se trouvait en régime haut (1-2 octobre, 3-4 octobre). * Aujourd'hui, tout à droite de la courbe, je constate une oscillation entre régime haut et régime intermédiaire. Je n'ai pas été devant la machine de toute la journée. Hypothèses: * Puisque le changement de noyau produit un changement de comportement, on peut supposer que le problème est dans le noyau, ou du moins lié au noyau. * On dirait que le programme qui s'enclenche peu après minuit cherche à régler le débit sur un régime qu'il estime soutenable à moyen terme. (Rappel: c'est du RAID1 sur deux disques SSD modernes, il devrait sans problème pouvoir tenir 1000 Mo/s.) Signe peut-être que des développeurs ont eu conscience d'un problème et qu'ils ont cherché à amenuiser ses conséquences, sans résoudre vraiment la question de fond cependant. À ce stade, je me suis dit qu'il serait judicieux d'installer le tout dernier noyau mais... c'est le 4.12 en fait, celui que j'ai mis il y a quelques jours. Il me reste donc deux options: * Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas ce problème. * Appeler en crontab chaque heure le contournement ponctuel de Jean-Bernard. La deuxième solution est crado, mais je ne connais pas ses vrais inconvénients (risques de plantage ?). Les connaissez-vous ? Et entre les deux, que me conseillez-vous ? Une idée pour une troisième option ? (À part bug-fixer le noyau :-) Seb. ---1155178722-623620097-1507143937=:14487--
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Pour finir, je sais obtenir un retour a des performances normales en vidant
le cache :
sync ; echo 2 > /proc/sys/vm/drop_caches
et comme toi, j'ai une nouvelle dégradation violente au bout d'un certain
temps.
Il y a quelques jours, j'ai passé la machine à la maison (Debian 9 stable)
sur le noyau 4.12.0-0.bpo.1-686-pae (backports). J'ai continué à mesurer
la performance des disques avec cette nouvelle situation. Voici le
résultat:
https://framapic.org/bFa8E3Zz3aJA/3vFMDsmo5LhF.png
J'observe ceci:
* La vitesse normale de la partition mesurée (par un simple 'dd') est
d'environ 1000 Mo/s. Cette vitesse est atteinte si j'appelle à la main la
commande envoyée par Jean-Bernard:
sync; echo 2 >! /proc/sys/vm/drop_caches
* Le système n'est toujours pas stable à cette vitesse, mais quand le
débit chute, après quelques heures seulement, il peut se stabiliser vers
150 Mo/s (1er octobre) ou (comme avant) à < 1 Mo/s (4 octobre). La chute
est toujours aussi brutale.
* Au régime intermédiaire 150 Mo/s, le système finit par retomber
spontanément au régime bas < 1 Mo/s.
* Dans les minutes qui suivent minuit, auparavant quelque chose dans le
système (dans le noyau ?) envoyait la machine en régime bas; maintenant,
cette même chose la remet en régime intermédiaire si elle se trouvait en
régime bas (2-3 octobre) mais aussi si elle se trouvait en régime haut
(1-2 octobre, 3-4 octobre).
* Aujourd'hui, tout à droite de la courbe, je constate une oscillation
entre régime haut et régime intermédiaire. Je n'ai pas été devant la
machine de toute la journée.
Hypothèses:
* Puisque le changement de noyau produit un changement de comportement, on
peut supposer que le problème est dans le noyau, ou du moins lié au noyau.
* On dirait que le programme qui s'enclenche peu après minuit cherche à
régler le débit sur un régime qu'il estime soutenable à moyen terme.
(Rappel: c'est du RAID1 sur deux disques SSD modernes, il devrait sans
problème pouvoir tenir 1000 Mo/s.) Signe peut-être que des développeurs
ont eu conscience d'un problème et qu'ils ont cherché à amenuiser ses
conséquences, sans résoudre vraiment la question de fond cependant.
À ce stade, je me suis dit qu'il serait judicieux d'installer le tout
dernier noyau mais... c'est le 4.12 en fait, celui que j'ai mis il y a
quelques jours.
Il me reste donc deux options:
* Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas ce
problème.
* Appeler en crontab chaque heure le contournement ponctuel de
Jean-Bernard.
La deuxième solution est crado, mais je ne connais pas ses vrais
inconvénients (risques de plantage ?). Les connaissez-vous ?
Et entre les deux, que me conseillez-vous ?
Une idée pour une troisième option ? (À part bug-fixer le noyau :-)
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-623620097-1507143937=:14487 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: Bonjour,
Pour finir, je sais obtenir un retour a des performances normales en vidant le cache : sync ; echo 2 > /proc/sys/vm/drop_caches et comme toi, j'ai une nouvelle dégradation violente au bout d'un certain temps.
Il y a quelques jours, j'ai passé la machine à la maison (Debian 9 stable) sur le noyau 4.12.0-0.bpo.1-686-pae (backports). J'ai continué à mesurer la performance des disques avec cette nouvelle situation. Voici le résultat: https://framapic.org/bFa8E3Zz3aJA/3vFMDsmo5LhF.png J'observe ceci: * La vitesse normale de la partition mesurée (par un simple 'dd') est d'environ 1000 Mo/s. Cette vitesse est atteinte si j'appelle à la main la commande envoyée par Jean-Bernard: sync; echo 2 >! /proc/sys/vm/drop_caches * Le système n'est toujours pas stable à cette vitesse, mais quand le débit chute, après quelques heures seulement, il peut se stabiliser vers 150 Mo/s (1er octobre) ou (comme avant) à < 1 Mo/s (4 octobre). La chute est toujours aussi brutale. * Au régime intermédiaire 150 Mo/s, le système finit par retomber spontanément au régime bas < 1 Mo/s. * Dans les minutes qui suivent minuit, auparavant quelque chose dans le système (dans le noyau ?) envoyait la machine en régime bas; maintenant, cette même chose la remet en régime intermédiaire si elle se trouvait en régime bas (2-3 octobre) mais aussi si elle se trouvait en régime haut (1-2 octobre, 3-4 octobre). * Aujourd'hui, tout à droite de la courbe, je constate une oscillation entre régime haut et régime intermédiaire. Je n'ai pas été devant la machine de toute la journée. Hypothèses: * Puisque le changement de noyau produit un changement de comportement, on peut supposer que le problème est dans le noyau, ou du moins lié au noyau. * On dirait que le programme qui s'enclenche peu après minuit cherche à régler le débit sur un régime qu'il estime soutenable à moyen terme. (Rappel: c'est du RAID1 sur deux disques SSD modernes, il devrait sans problème pouvoir tenir 1000 Mo/s.) Signe peut-être que des développeurs ont eu conscience d'un problème et qu'ils ont cherché à amenuiser ses conséquences, sans résoudre vraiment la question de fond cependant. À ce stade, je me suis dit qu'il serait judicieux d'installer le tout dernier noyau mais... c'est le 4.12 en fait, celui que j'ai mis il y a quelques jours. Il me reste donc deux options: * Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas ce problème. * Appeler en crontab chaque heure le contournement ponctuel de Jean-Bernard. La deuxième solution est crado, mais je ne connais pas ses vrais inconvénients (risques de plantage ?). Les connaissez-vous ? Et entre les deux, que me conseillez-vous ? Une idée pour une troisième option ? (À part bug-fixer le noyau :-) Seb. ---1155178722-623620097-1507143937=:14487--
Thierry Bugier
Bonjour Le mercredi 04 octobre 2017 à 21:13 +0200, Seb a écrit :
Il me reste donc deux options: * Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas ce problème. * Appeler en crontab chaque heure le contournement ponctuel de Jean-Bernard. La deuxième solution est crado, mais je ne connais pas ses vrais inconvénients (risques de plantage ?). Les connaissez-vous ? Et entre les deux, que me conseillez-vous ? Une idée pour une troisième option ? (À part bug-fixer le noyau :-)
Idée de troisième solution à faire en parallèle d'un contournement: se rapprocher des développeurs du kernel pour signaler qu'il y a probablement un bug. Je pense qu'il n'y pas plus vraiment de doute l'existence d'un bug. Peut être que eux, justement, pourront proposer un contournement fiable en attendant la release du correctif.
Seb.
Bonjour
Le mercredi 04 octobre 2017 à 21:13 +0200, Seb a écrit :
Il me reste donc deux options:
* Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas
ce
problème.
* Appeler en crontab chaque heure le contournement ponctuel de
Jean-Bernard.
La deuxième solution est crado, mais je ne connais pas ses vrais
inconvénients (risques de plantage ?). Les connaissez-vous ?
Et entre les deux, que me conseillez-vous ?
Une idée pour une troisième option ? (À part bug-fixer le noyau :-)
Idée de troisième solution à faire en parallèle d'un contournement: se
rapprocher des développeurs du kernel pour signaler qu'il y a
probablement un bug. Je pense qu'il n'y pas plus vraiment de doute
l'existence d'un bug. Peut être que eux, justement, pourront proposer
un contournement fiable en attendant la release du correctif.
Bonjour Le mercredi 04 octobre 2017 à 21:13 +0200, Seb a écrit :
Il me reste donc deux options: * Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas ce problème. * Appeler en crontab chaque heure le contournement ponctuel de Jean-Bernard. La deuxième solution est crado, mais je ne connais pas ses vrais inconvénients (risques de plantage ?). Les connaissez-vous ? Et entre les deux, que me conseillez-vous ? Une idée pour une troisième option ? (À part bug-fixer le noyau :-)
Idée de troisième solution à faire en parallèle d'un contournement: se rapprocher des développeurs du kernel pour signaler qu'il y a probablement un bug. Je pense qu'il n'y pas plus vraiment de doute l'existence d'un bug. Peut être que eux, justement, pourront proposer un contournement fiable en attendant la release du correctif.
Seb.
Pascal Hambourg
Le 04/10/2017 à 21:13, Seb a écrit :
Il me reste donc deux options: * Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas ce problème. * Appeler en crontab chaque heure le contournement ponctuel de Jean-Bernard. La deuxième solution est crado, mais je ne connais pas ses vrais inconvénients (risques de plantage ?). Les connaissez-vous ?
L'inconvénient, c'est l'effet pour lequel elle a été conçue : le vidage du cache des méta-données des systèmes de fichiers, obligeant le noyau à relire ces méta-données depuis les disques en cas de besoin. Avec des SSD, l'impact négatif doit être moins sensible.
Et entre les deux, que me conseillez-vous ?
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait : utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
Le 04/10/2017 à 21:13, Seb a écrit :
Il me reste donc deux options:
* Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas ce
problème.
* Appeler en crontab chaque heure le contournement ponctuel de
Jean-Bernard.
La deuxième solution est crado, mais je ne connais pas ses vrais
inconvénients (risques de plantage ?). Les connaissez-vous ?
L'inconvénient, c'est l'effet pour lequel elle a été conçue : le vidage
du cache des méta-données des systèmes de fichiers, obligeant le noyau à
relire ces méta-données depuis les disques en cas de besoin. Avec des
SSD, l'impact négatif doit être moins sensible.
Et entre les deux, que me conseillez-vous ?
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait :
utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
Il me reste donc deux options: * Effacer la Debian 9, installer une Debian 8 qui, elle, n'avait pas ce problème. * Appeler en crontab chaque heure le contournement ponctuel de Jean-Bernard. La deuxième solution est crado, mais je ne connais pas ses vrais inconvénients (risques de plantage ?). Les connaissez-vous ?
L'inconvénient, c'est l'effet pour lequel elle a été conçue : le vidage du cache des méta-données des systèmes de fichiers, obligeant le noyau à relire ces méta-données depuis les disques en cas de besoin. Avec des SSD, l'impact négatif doit être moins sensible.
Et entre les deux, que me conseillez-vous ?
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait : utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
Seb
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1215871488-1507191892=:17980 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Bonjour Pascal,
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait : utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
Ah oui, c'est une bonne idée. Si j'appelle sur une machine en Debian 9 apt-cache search linux-image je ne vois pas de noyau 3.16 . Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de solution packagée indiquée; d'un autre côté, elle ne mentionne pas non plus les backports pour avoir, au contraire, un noyau plus récent. Y a-t-il une méthode standard Debian qui me permettrait d'installer sans trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne page web m'irait amplement.) Il y a bien longtemps de cela, dans les années 1990, je compilais mes noyaux à la main; ensuite il y a eu trop d'options dans le noyau pour que cela reste raisonnable (et puis il fallait aussi s'occuper d'initramfs, puis grub a supplanté lilo), bref par commodité je n'ai plus utilisé que le noyau pré-packagé depuis une quinzaine d'années. Faute d'expérience récente, j'aimerais bien éviter de replonger les mains trop profondément dans le système, sans outils Debian dédiés il est presque sûr que j'obtiendrais au mieux une machine qui ne boote plus. Seb. ---1155178722-1215871488-1507191892=:17980--
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait :
utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
Ah oui, c'est une bonne idée.
Si j'appelle sur une machine en Debian 9
apt-cache search linux-image
je ne vois pas de noyau 3.16 .
Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de
solution packagée indiquée; d'un autre côté, elle ne mentionne pas non
plus les backports pour avoir, au contraire, un noyau plus récent.
Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
page web m'irait amplement.)
Il y a bien longtemps de cela, dans les années 1990, je compilais mes
noyaux à la main; ensuite il y a eu trop d'options dans le noyau pour que
cela reste raisonnable (et puis il fallait aussi s'occuper d'initramfs,
puis grub a supplanté lilo), bref par commodité je n'ai plus utilisé que
le noyau pré-packagé depuis une quinzaine d'années. Faute d'expérience
récente, j'aimerais bien éviter de replonger les mains trop profondément
dans le système, sans outils Debian dédiés il est presque sûr que
j'obtiendrais au mieux une machine qui ne boote plus.
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1215871488-1507191892=:17980 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Bonjour Pascal,
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait : utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?
Ah oui, c'est une bonne idée. Si j'appelle sur une machine en Debian 9 apt-cache search linux-image je ne vois pas de noyau 3.16 . Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de solution packagée indiquée; d'un autre côté, elle ne mentionne pas non plus les backports pour avoir, au contraire, un noyau plus récent. Y a-t-il une méthode standard Debian qui me permettrait d'installer sans trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne page web m'irait amplement.) Il y a bien longtemps de cela, dans les années 1990, je compilais mes noyaux à la main; ensuite il y a eu trop d'options dans le noyau pour que cela reste raisonnable (et puis il fallait aussi s'occuper d'initramfs, puis grub a supplanté lilo), bref par commodité je n'ai plus utilisé que le noyau pré-packagé depuis une quinzaine d'années. Faute d'expérience récente, j'aimerais bien éviter de replonger les mains trop profondément dans le système, sans outils Debian dédiés il est presque sûr que j'obtiendrais au mieux une machine qui ne boote plus. Seb. ---1155178722-1215871488-1507191892=:17980--
