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 -
Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée être du "fakeraid"...
A quoi d'autre t'attendais-tu ? Seules les grosses cartes RAID chères font du vrai RAID matériel. Donc on oublie le fakeRAID et on utilise le RAID logiciel natif de Linux, bien plus stable et fiable que n'importe quel fakeRAID dépendant du matériel dont le seul avantage est la compatibilité avec Windows.
Possibilité d'installer et d'utiliser le Raid0 qui était dessus, mais il finissait par perdre les perfs jusqu'à l'octet/s :s Souvent la machine freezait de longs moments ! Par contre c'était cool avec Windows.
C'est-à-dire ?
Ca sentait le "pilote" intégré à Debian,
C'est-à-dire ?
selon mon avis par déduction absolument pas expert en la matière ;) Peut-être suis-je complètement à coté de la plaque !!!
Etant donné que je ne vois absolument pas ce que tu veux dire, je suis bien incapable d'émettre un avis sur la question.
J'ai souvenir que pour installer Debian sur du raid, il fallait absolument ajouter dmraid=true dans la ligne de commande du cd d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc géré par l'OS ?
Uniquement pour le fakeRAID. Pas nécessaire pour utiliser le RAID logiciel natif de Linux (md).
Le 23/09/2017 à 08:50, Pierre L. a écrit :
Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite
carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée
être du "fakeraid"...
A quoi d'autre t'attendais-tu ?
Seules les grosses cartes RAID chères font du vrai RAID matériel.
Donc on oublie le fakeRAID et on utilise le RAID logiciel natif de
Linux, bien plus stable et fiable que n'importe quel fakeRAID dépendant
du matériel dont le seul avantage est la compatibilité avec Windows.
Possibilité d'installer et d'utiliser le Raid0 qui
était dessus, mais il finissait par perdre les perfs jusqu'à l'octet/s :s
Souvent la machine freezait de longs moments !
Par contre c'était cool avec Windows.
C'est-à-dire ?
Ca sentait le "pilote" intégré à Debian,
C'est-à-dire ?
selon mon avis par déduction absolument pas expert en la matière ;)
Peut-être suis-je complètement à coté de la plaque !!!
Etant donné que je ne vois absolument pas ce que tu veux dire, je suis
bien incapable d'émettre un avis sur la question.
J'ai souvenir que pour installer Debian sur du raid, il fallait
absolument ajouter dmraid=true dans la ligne de commande du cd
d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc
géré par l'OS ?
Uniquement pour le fakeRAID. Pas nécessaire pour utiliser le RAID
logiciel natif de Linux (md).
Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée être du "fakeraid"...
A quoi d'autre t'attendais-tu ? Seules les grosses cartes RAID chères font du vrai RAID matériel. Donc on oublie le fakeRAID et on utilise le RAID logiciel natif de Linux, bien plus stable et fiable que n'importe quel fakeRAID dépendant du matériel dont le seul avantage est la compatibilité avec Windows.
Possibilité d'installer et d'utiliser le Raid0 qui était dessus, mais il finissait par perdre les perfs jusqu'à l'octet/s :s Souvent la machine freezait de longs moments ! Par contre c'était cool avec Windows.
C'est-à-dire ?
Ca sentait le "pilote" intégré à Debian,
C'est-à-dire ?
selon mon avis par déduction absolument pas expert en la matière ;) Peut-être suis-je complètement à coté de la plaque !!!
Etant donné que je ne vois absolument pas ce que tu veux dire, je suis bien incapable d'émettre un avis sur la question.
J'ai souvenir que pour installer Debian sur du raid, il fallait absolument ajouter dmraid=true dans la ligne de commande du cd d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc géré par l'OS ?
Uniquement pour le fakeRAID. Pas nécessaire pour utiliser le RAID logiciel natif de Linux (md).
Pascal Hambourg
Le 23/09/2017 à 11:57, Seb a écrit :
Après j'avoue que ca m'a toujours un peu perdu ces histoires de fakeraid...
J'aurais dû préciser quelque chose qui n'était qu'implicite dans mon message initial: tout mes tableaux RAID sont en soft, gérés par 'mdadm'.
C'était clairement indiqué dans le contenu de /proc/mdstat. PS : les uns et les autres, ce serait sympa pour les lecteurs d'élaguer les citations inutiles des messages auxquels vous répondez.
Le 23/09/2017 à 11:57, Seb a écrit :
Après j'avoue que ca m'a toujours un peu perdu ces histoires de
fakeraid...
J'aurais dû préciser quelque chose qui n'était qu'implicite dans mon
message initial: tout mes tableaux RAID sont en soft, gérés par 'mdadm'.
C'était clairement indiqué dans le contenu de /proc/mdstat.
PS : les uns et les autres, ce serait sympa pour les lecteurs d'élaguer
les citations inutiles des messages auxquels vous répondez.
Après j'avoue que ca m'a toujours un peu perdu ces histoires de fakeraid...
J'aurais dû préciser quelque chose qui n'était qu'implicite dans mon message initial: tout mes tableaux RAID sont en soft, gérés par 'mdadm'.
C'était clairement indiqué dans le contenu de /proc/mdstat. PS : les uns et les autres, ce serait sympa pour les lecteurs d'élaguer les citations inutiles des messages auxquels vous répondez.
Jean-Michel OLTRA
Bonjour, Le samedi 23 septembre 2017, Pascal Hambourg a écrit...
PS : les uns et les autres, ce serait sympa pour les lecteurs d'élaguer les citations inutiles des messages auxquels vous répondez.
+1 -- jm
Bonjour,
Le samedi 23 septembre 2017, Pascal Hambourg a écrit...
PS : les uns et les autres, ce serait sympa pour les lecteurs d'élaguer les
citations inutiles des messages auxquels vous répondez.
Bonjour, Le samedi 23 septembre 2017, Pascal Hambourg a écrit...
PS : les uns et les autres, ce serait sympa pour les lecteurs d'élaguer les citations inutiles des messages auxquels vous répondez.
+1 -- jm
Pascal Hambourg
Le 23/09/2017 à 15:51, Pierre L. a écrit :
Le 23/09/2017 à 10:40, Pascal Hambourg a écrit :
Le 23/09/2017 à 08:50, Pierre L. a écrit :
Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée être du "fakeraid"...
A quoi d'autre t'attendais-tu ?
Tu n'as jamais été jeune ?!
Je le suis encore, mais il y a longtemps que j'ai arrêté de croire au père Noël.
Ca sentait le "pilote" intégré à Debian,
C'est-à-dire ?
Pure réflexion de quelqu'un qui n'est (je cite ma précédente réponse) "absolument pas expert en la matière ;)"
Cela n'explique toujours pas ce que tu entends par "pilote intégré à Debian".
Les échanges sont faits pour s'enrichir en connaissance !
A condition de se comprendre.
J'ai souvenir que pour installer Debian sur du raid, il fallait absolument ajouter dmraid=true dans la ligne de commande du cd d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc géré par l'OS ?
Uniquement pour le fakeRAID. Pas nécessaire pour utiliser le RAID logiciel natif de Linux (md).
Donc si j'ai bien compris le principe, si on configure notre chipset de carte mère (un truc de bureau hein) pour faire du fakeraid (ok ?)
Oui.
Le 23/09/2017 à 15:51, Pierre L. a écrit :
Le 23/09/2017 à 10:40, Pascal Hambourg a écrit :
Le 23/09/2017 à 08:50, Pierre L. a écrit :
Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite
carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée
être du "fakeraid"...
A quoi d'autre t'attendais-tu ?
Tu n'as jamais été jeune ?!
Je le suis encore, mais il y a longtemps que j'ai arrêté de croire au
père Noël.
Ca sentait le "pilote" intégré à Debian,
C'est-à-dire ?
Pure réflexion de quelqu'un qui n'est (je cite ma précédente réponse)
"absolument pas expert en la matière ;)"
Cela n'explique toujours pas ce que tu entends par "pilote intégré à
Debian".
Les échanges sont faits pour s'enrichir en connaissance !
A condition de se comprendre.
J'ai souvenir que pour installer Debian sur du raid, il fallait
absolument ajouter dmraid=true dans la ligne de commande du cd
d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc
géré par l'OS ?
Uniquement pour le fakeRAID. Pas nécessaire pour utiliser le RAID
logiciel natif de Linux (md).
Donc si j'ai bien compris le principe, si on configure notre chipset de
carte mère (un truc de bureau hein) pour faire du fakeraid (ok ?)
Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée être du "fakeraid"...
A quoi d'autre t'attendais-tu ?
Tu n'as jamais été jeune ?!
Je le suis encore, mais il y a longtemps que j'ai arrêté de croire au père Noël.
Ca sentait le "pilote" intégré à Debian,
C'est-à-dire ?
Pure réflexion de quelqu'un qui n'est (je cite ma précédente réponse) "absolument pas expert en la matière ;)"
Cela n'explique toujours pas ce que tu entends par "pilote intégré à Debian".
Les échanges sont faits pour s'enrichir en connaissance !
A condition de se comprendre.
J'ai souvenir que pour installer Debian sur du raid, il fallait absolument ajouter dmraid=true dans la ligne de commande du cd d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc géré par l'OS ?
Uniquement pour le fakeRAID. Pas nécessaire pour utiliser le RAID logiciel natif de Linux (md).
Donc si j'ai bien compris le principe, si on configure notre chipset de carte mère (un truc de bureau hein) pour faire du fakeraid (ok ?)
Oui.
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-1945093857-1506260545=:3785 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Bonjour,
Je serais fort surpris que le problème soit lié aux disques: * un reboot résout le problème pour plusieurs heures; * ces disques fonctionnaient parfaitement juste avant le passage en Debian 9, et incorrectement juste après;
Tu as essayé avec d'autres versions du noyau ?
En un sens oui, puisque le problème est apparu sur une machine avec l'installation de la Debian 8, version de janvier 2017, et sur l'autre avec l'installation de la Debian 9. Sauf erreur, le noyau n'est pas le même dans la Debian 8 de janvier 2017 et dans la Debian 9 de juillet 2017. Au fait, je voulais vous envoyer un graphique qui montre le débit du tableau RAID sur une période de 24 h, mais mon courrier n'atteint jamais la liste quand il contient une pièce jointe (j'ai essayé les formats PDF et JPEG). Quelle serait la bonne manière de procéder ? Seb. ---1155178722-1945093857-1506260545=:3785--
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 serais fort surpris que le problème soit lié aux disques:
* un reboot résout le problème pour plusieurs heures;
* ces disques fonctionnaient parfaitement juste avant le passage en
Debian 9, et incorrectement juste après;
Tu as essayé avec d'autres versions du noyau ?
En un sens oui, puisque le problème est apparu sur une machine avec
l'installation de la Debian 8, version de janvier 2017, et sur l'autre
avec l'installation de la Debian 9. Sauf erreur, le noyau n'est pas le
même dans la Debian 8 de janvier 2017 et dans la Debian 9 de juillet 2017.
Au fait, je voulais vous envoyer un graphique qui montre le débit du
tableau RAID sur une période de 24 h, mais mon courrier n'atteint jamais
la liste quand il contient une pièce jointe (j'ai essayé les formats PDF
et JPEG). Quelle serait la bonne manière de procéder ?
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-1945093857-1506260545=:3785 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Bonjour,
Je serais fort surpris que le problème soit lié aux disques: * un reboot résout le problème pour plusieurs heures; * ces disques fonctionnaient parfaitement juste avant le passage en Debian 9, et incorrectement juste après;
Tu as essayé avec d'autres versions du noyau ?
En un sens oui, puisque le problème est apparu sur une machine avec l'installation de la Debian 8, version de janvier 2017, et sur l'autre avec l'installation de la Debian 9. Sauf erreur, le noyau n'est pas le même dans la Debian 8 de janvier 2017 et dans la Debian 9 de juillet 2017. Au fait, je voulais vous envoyer un graphique qui montre le débit du tableau RAID sur une période de 24 h, mais mon courrier n'atteint jamais la liste quand il contient une pièce jointe (j'ai essayé les formats PDF et JPEG). Quelle serait la bonne manière de procéder ? Seb. ---1155178722-1945093857-1506260545=:3785--
Thierry Bugier
Bonjour Le dimanche 24 septembre 2017 à 15:42 +0200, Seb a écrit :
Bonjour,
Je serais fort surpris que le problème soit lié aux disques: * un reboot résout le problème pour plusieurs heures; * ces disques fonctionnaient parfaitement juste avant le passage
en
Debian 9, et incorrectement juste après;
Tu as essayé avec d'autres versions du noyau ?
En un sens oui, puisque le problème est apparu sur une machine avec l'installation de la Debian 8, version de janvier 2017, et sur l'autre avec l'installation de la Debian 9. Sauf erreur, le noyau n'est pas le même dans la Debian 8 de janvier 2017 et dans la Debian 9 de juillet 2017.
Pour info je suis avec Debian Sid et j'ai un RAID 1 ainsi qu'un RAID 0 sur 2 paires de disques magnétiques. Pour être précis voici leur empilement (si je puis dire): Disques durs / RAID / LVM / systèmes de fichiers Aucun souci constaté niveau performances et le RAID 1. Si il y a bug, alors il est peut être en lien avec le fait que les disques de Seb soient en SSD. Ca me fait venir une idée : monter un RAID 1 sur disques magnétiques avec quelques Go de données, puis utiliser un logiciel quelconque pour lire ou même écrire dessus. Ce serait intéressant de voir si les performances finissent par chuter. Le but serait de voir si oui ou non la technologie des disques est déterminante pour faire apparaître le souci. H.S.: dans mes brèves recherches sur ce problème, je suis tombé sur autre chose d'assez intéressant : un raid 1 hybride HDD / SSD pour avoir un RAID 1 performant sans se ruiner avec 2 SSD. https://www.bibinsa.net/post/2015/02/16/Hybrid-RAID-SSD-HDD-avec-Linux Je sens que je vais essayer.
Seb.
Bonjour
Le dimanche 24 septembre 2017 à 15:42 +0200, Seb a écrit :
Bonjour,
>> Je serais fort surpris que le problème soit lié aux disques:
>>
>> * un reboot résout le problème pour plusieurs heures;
>>
>> * ces disques fonctionnaient parfaitement juste avant le passage
en
>> Debian 9, et incorrectement juste après;
>
> Tu as essayé avec d'autres versions du noyau ?
En un sens oui, puisque le problème est apparu sur une machine avec
l'installation de la Debian 8, version de janvier 2017, et sur
l'autre
avec l'installation de la Debian 9. Sauf erreur, le noyau n'est pas
le
même dans la Debian 8 de janvier 2017 et dans la Debian 9 de juillet
2017.
Pour info je suis avec Debian Sid et j'ai un RAID 1 ainsi qu'un RAID 0
sur 2 paires de disques magnétiques. Pour être précis voici leur
empilement (si je puis dire):
Disques durs / RAID / LVM / systèmes de fichiers
Aucun souci constaté niveau performances et le RAID 1. Si il y a bug,
alors il est peut être en lien avec le fait que les disques de Seb
soient en SSD.
Ca me fait venir une idée : monter un RAID 1 sur disques magnétiques
avec quelques Go de données, puis utiliser un logiciel quelconque pour
lire ou même écrire dessus. Ce serait intéressant de voir si les
performances finissent par chuter. Le but serait de voir si oui ou non
la technologie des disques est déterminante pour faire apparaître le
souci.
H.S.: dans mes brèves recherches sur ce problème, je suis tombé sur
autre chose d'assez intéressant : un raid 1 hybride HDD / SSD pour
avoir un RAID 1 performant sans se ruiner avec 2 SSD.
Bonjour Le dimanche 24 septembre 2017 à 15:42 +0200, Seb a écrit :
Bonjour,
Je serais fort surpris que le problème soit lié aux disques: * un reboot résout le problème pour plusieurs heures; * ces disques fonctionnaient parfaitement juste avant le passage
en
Debian 9, et incorrectement juste après;
Tu as essayé avec d'autres versions du noyau ?
En un sens oui, puisque le problème est apparu sur une machine avec l'installation de la Debian 8, version de janvier 2017, et sur l'autre avec l'installation de la Debian 9. Sauf erreur, le noyau n'est pas le même dans la Debian 8 de janvier 2017 et dans la Debian 9 de juillet 2017.
Pour info je suis avec Debian Sid et j'ai un RAID 1 ainsi qu'un RAID 0 sur 2 paires de disques magnétiques. Pour être précis voici leur empilement (si je puis dire): Disques durs / RAID / LVM / systèmes de fichiers Aucun souci constaté niveau performances et le RAID 1. Si il y a bug, alors il est peut être en lien avec le fait que les disques de Seb soient en SSD. Ca me fait venir une idée : monter un RAID 1 sur disques magnétiques avec quelques Go de données, puis utiliser un logiciel quelconque pour lire ou même écrire dessus. Ce serait intéressant de voir si les performances finissent par chuter. Le but serait de voir si oui ou non la technologie des disques est déterminante pour faire apparaître le souci. H.S.: dans mes brèves recherches sur ce problème, je suis tombé sur autre chose d'assez intéressant : un raid 1 hybride HDD / SSD pour avoir un RAID 1 performant sans se ruiner avec 2 SSD. https://www.bibinsa.net/post/2015/02/16/Hybrid-RAID-SSD-HDD-avec-Linux Je sens que je vais essayer.
Seb.
Thierry Bugier
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 ?
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 ?
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 ?
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-1334908332-1506455276=:29409 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: 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 ?
Pour finir, je sais obtenir un retour a des performances normales en vidant le cache : sync ; echo 2 > /proc/sys/vm/drop_caches
Super, merci pour cette astuce; je l'ai testée tout à l'heure, elle fonctionne aussi chez moi. C'est déjà un soulagement de ne plus avoir à rebooter... Même si cela soigne les symptômes sans s'attaquer à la racine du problème.
En espérant avoir apporté un élément nouveau qui puisse aider a comprendre, je suis moi aussi avide d'une solution.
J'ai utilisé "/proc/sys/vm/drop_caches" comme mot-clef dans Google. La ligne de commande que tu indiques demande au noyau de libérer la RAM qu'il avait allouée pour mettre en cache les fichiers et répertoires qu'il a lus. C'est très bizarre que ceci influence la vitesse de nos tableaux RAID car cette portion de RAM est supposée être réutilisable dès qu'un besoin réel se présente. En outre, sur une machine qui est actuellement coincée à des débits de 1 Mo/s, j'ai: ~>free -m total used free shared buff/cache available Mem: 7980 773 6125 172 1080 6278 Swap: 3813 0 3813 Sur 8 Go de RAM, plus de 6 Go sont disponibles. On ne peut pas qu'il y ait un manque. Par ailleurs, j'ai suivi le conseil donné par Thierry Bugier: dans la machine à la maison, j'ai branché deux disques à plateaux que j'avais remisés, assemblé un RAID1 pour faire une partition (10 Go, JFS, aucun fichier) et j'ai enregistré leur débit. J'ai uploadé sur framapic deux images parlantes: Bureau: https://framapic.org/gallery#Pn5Jx4AuzmI3/5cUOEH82OcpU.png Maison: https://framapic.org/mt5DVGNW6QXb/lWj5EGz6jZJ6.png Elles représentent le débit, mesuré grossièrement avec 'dd', de la partition montée en racine, de la partition montée en /home et, pour la machine à la maison, de la partition construite avec les disques à plateaux. (L'excellent débit des disques à plateaux est dû à la petite taille -- 10 Mo -- du fichier que je crée avec 'dd': on reste dans les caches des disques.) On observe d'abord une excellente concordance des performances: elles chutent en même temps sur des filesystems différents. Ce n'est donc pas, par exemple, un problème de fsck. En outre, ce n'est pas lié aux disques SSD puisque la partition sur les disques à plateaux montre les mêmes symptômes. Je constate aussi une chute dans le premier quart d'heure après minuit pour toutes les partitions (2 au bureau, 3 à la maison). Or je n'ai aucune crontab, en utilisateur ou en root, qui se lance dans cette tranche horaire, sur aucune des deux machines. Cela pointe vers une action du système juste après minuit. Quand je regarde /etc/crontab, cependant, je vois que les cron.daily sont lancées à 6h25 le matin. Est-ce que quelqu'un a une idée pour identifier ce qui se passe peu après minuit dans la Debian ? Pour continuer les tests, je viens de passer en ext4 la partition des disques à plateaux, on verra si elle continue à suivre les autres... Merci pour votre aide. Seb. ---1155178722-1334908332-1506455276=:29409--
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
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 ?
Pour finir, je sais obtenir un retour a des performances normales en vidant
le cache :
sync ; echo 2 > /proc/sys/vm/drop_caches
Super, merci pour cette astuce; je l'ai testée tout à l'heure, elle
fonctionne aussi chez moi. C'est déjà un soulagement de ne plus avoir à
rebooter... Même si cela soigne les symptômes sans s'attaquer à la racine
du problème.
En espérant avoir apporté un élément nouveau qui puisse aider a
comprendre, je suis moi aussi avide d'une solution.
J'ai utilisé "/proc/sys/vm/drop_caches" comme mot-clef dans Google. La
ligne de commande que tu indiques demande au noyau de libérer la RAM qu'il
avait allouée pour mettre en cache les fichiers et répertoires qu'il a
lus. C'est très bizarre que ceci influence la vitesse de nos tableaux RAID
car cette portion de RAM est supposée être réutilisable dès qu'un besoin
réel se présente. En outre, sur une machine qui est actuellement coincée à
des débits de 1 Mo/s, j'ai:
~>free -m
total used free shared buff/cache available
Mem: 7980 773 6125 172 1080 6278
Swap: 3813 0 3813
Sur 8 Go de RAM, plus de 6 Go sont disponibles. On ne peut pas qu'il y ait
un manque.
Par ailleurs, j'ai suivi le conseil donné par Thierry Bugier: dans la
machine à la maison, j'ai branché deux disques à plateaux que j'avais
remisés, assemblé un RAID1 pour faire une partition (10 Go, JFS, aucun
fichier) et j'ai enregistré leur débit. J'ai uploadé sur framapic deux
images parlantes:
Elles représentent le débit, mesuré grossièrement avec 'dd', de la
partition montée en racine, de la partition montée en /home et, pour la
machine à la maison, de la partition construite avec les disques à
plateaux. (L'excellent débit des disques à plateaux est dû à la petite
taille -- 10 Mo -- du fichier que je crée avec 'dd': on reste dans les
caches des disques.)
On observe d'abord une excellente concordance des performances: elles
chutent en même temps sur des filesystems différents. Ce n'est donc pas,
par exemple, un problème de fsck. En outre, ce n'est pas lié aux disques
SSD puisque la partition sur les disques à plateaux montre les mêmes
symptômes.
Je constate aussi une chute dans le premier quart d'heure après minuit
pour toutes les partitions (2 au bureau, 3 à la maison). Or je n'ai aucune
crontab, en utilisateur ou en root, qui se lance dans cette tranche
horaire, sur aucune des deux machines.
Cela pointe vers une action du système juste après minuit. Quand je
regarde /etc/crontab, cependant, je vois que les cron.daily sont lancées à
6h25 le matin. Est-ce que quelqu'un a une idée pour identifier ce qui se
passe peu après minuit dans la Debian ?
Pour continuer les tests, je viens de passer en ext4 la partition des
disques à plateaux, on verra si elle continue à suivre les autres...
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-1334908332-1506455276=:29409 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: 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 ?
Pour finir, je sais obtenir un retour a des performances normales en vidant le cache : sync ; echo 2 > /proc/sys/vm/drop_caches
Super, merci pour cette astuce; je l'ai testée tout à l'heure, elle fonctionne aussi chez moi. C'est déjà un soulagement de ne plus avoir à rebooter... Même si cela soigne les symptômes sans s'attaquer à la racine du problème.
En espérant avoir apporté un élément nouveau qui puisse aider a comprendre, je suis moi aussi avide d'une solution.
J'ai utilisé "/proc/sys/vm/drop_caches" comme mot-clef dans Google. La ligne de commande que tu indiques demande au noyau de libérer la RAM qu'il avait allouée pour mettre en cache les fichiers et répertoires qu'il a lus. C'est très bizarre que ceci influence la vitesse de nos tableaux RAID car cette portion de RAM est supposée être réutilisable dès qu'un besoin réel se présente. En outre, sur une machine qui est actuellement coincée à des débits de 1 Mo/s, j'ai: ~>free -m total used free shared buff/cache available Mem: 7980 773 6125 172 1080 6278 Swap: 3813 0 3813 Sur 8 Go de RAM, plus de 6 Go sont disponibles. On ne peut pas qu'il y ait un manque. Par ailleurs, j'ai suivi le conseil donné par Thierry Bugier: dans la machine à la maison, j'ai branché deux disques à plateaux que j'avais remisés, assemblé un RAID1 pour faire une partition (10 Go, JFS, aucun fichier) et j'ai enregistré leur débit. J'ai uploadé sur framapic deux images parlantes: Bureau: https://framapic.org/gallery#Pn5Jx4AuzmI3/5cUOEH82OcpU.png Maison: https://framapic.org/mt5DVGNW6QXb/lWj5EGz6jZJ6.png Elles représentent le débit, mesuré grossièrement avec 'dd', de la partition montée en racine, de la partition montée en /home et, pour la machine à la maison, de la partition construite avec les disques à plateaux. (L'excellent débit des disques à plateaux est dû à la petite taille -- 10 Mo -- du fichier que je crée avec 'dd': on reste dans les caches des disques.) On observe d'abord une excellente concordance des performances: elles chutent en même temps sur des filesystems différents. Ce n'est donc pas, par exemple, un problème de fsck. En outre, ce n'est pas lié aux disques SSD puisque la partition sur les disques à plateaux montre les mêmes symptômes. Je constate aussi une chute dans le premier quart d'heure après minuit pour toutes les partitions (2 au bureau, 3 à la maison). Or je n'ai aucune crontab, en utilisateur ou en root, qui se lance dans cette tranche horaire, sur aucune des deux machines. Cela pointe vers une action du système juste après minuit. Quand je regarde /etc/crontab, cependant, je vois que les cron.daily sont lancées à 6h25 le matin. Est-ce que quelqu'un a une idée pour identifier ce qui se passe peu après minuit dans la Debian ? Pour continuer les tests, je viens de passer en ext4 la partition des disques à plateaux, on verra si elle continue à suivre les autres... Merci pour votre aide. Seb. ---1155178722-1334908332-1506455276=:29409--
Pascal Hambourg
Le 27/09/2017 à 13:00, Seb a écrit :
Pour finir, je sais obtenir un retour a des performances normales en vidant le cache : sync ; echo 2 > /proc/sys/vm/drop_caches
(...)
J'ai utilisé "/proc/sys/vm/drop_caches" comme mot-clef dans Google. La ligne de commande que tu indiques demande au noyau de libérer la RAM qu'il avait allouée pour mettre en cache les fichiers et répertoires qu'il a lus.
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. La valeur affichée dans la colonne "cache" par la commande free ne prend en compte que le cache du contenu des fichiers, le "pagecache" et pas les caches de dentries et d'inodes. Le pagecache est vidé par la valeur 1. La valeur 3 vide les deux.
C'est très bizarre que ceci influence la vitesse de nos tableaux RAID car cette portion de RAM est supposée être réutilisable dès qu'un besoin réel se présente.
Et surtout, ces structures de données sont liées aux systèmes de fichiers montés et non aux périphériques bloc tels que les disques ou ensembles RAID.
En outre, sur une machine qui est actuellement coincée à des débits de 1 Mo/s, j'ai: ~>free -m total used free shared buff/cache available Mem: 7980 773 6125 172 1080 6278 Swap: 3813 0 3813 Sur 8 Go de RAM, plus de 6 Go sont disponibles. On ne peut pas qu'il y ait un manque.
Pour information, la mémoire occupée par les caches de dentries et d'inodes est comptée dans la colonne "used". Elle fait partie du "slab", dont on peut voir la taille dans /proc/meminfo et le détail dans /proc/slabinfo (chercher les colonnes contenant "inode" et "dentry"). 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 - en écriture dans le système de fichiers - 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) - même chose dans une partition classique non RAID - même chose avec d'autres types de systèmes de fichiers
Le 27/09/2017 à 13:00, Seb a écrit :
Pour finir, je sais obtenir un retour a des performances normales en
vidant le cache :
sync ; echo 2 > /proc/sys/vm/drop_caches
(...)
J'ai utilisé "/proc/sys/vm/drop_caches" comme mot-clef dans Google. La
ligne de commande que tu indiques demande au noyau de libérer la RAM
qu'il avait allouée pour mettre en cache les fichiers et répertoires
qu'il a lus.
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.
La valeur affichée dans la colonne "cache" par la commande free ne prend
en compte que le cache du contenu des fichiers, le "pagecache" et pas
les caches de dentries et d'inodes. Le pagecache est vidé par la valeur
1. La valeur 3 vide les deux.
C'est très bizarre que ceci influence la vitesse de nos
tableaux RAID car cette portion de RAM est supposée être réutilisable
dès qu'un besoin réel se présente.
Et surtout, ces structures de données sont liées aux systèmes de
fichiers montés et non aux périphériques bloc tels que les disques ou
ensembles RAID.
En outre, sur une machine qui est
actuellement coincée à des débits de 1 Mo/s, j'ai:
~>free -m
total used free shared buff/cache
available
Mem: 7980 773 6125 172 1080 6278
Swap: 3813 0 3813
Sur 8 Go de RAM, plus de 6 Go sont disponibles. On ne peut pas qu'il y
ait un manque.
Pour information, la mémoire occupée par les caches de dentries et
d'inodes est comptée dans la colonne "used". Elle fait partie du "slab",
dont on peut voir la taille dans /proc/meminfo et le détail dans
/proc/slabinfo (chercher les colonnes contenant "inode" et "dentry").
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
- en écriture dans le système de fichiers
- 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)
- même chose dans une partition classique non RAID
- même chose avec d'autres types de systèmes de fichiers
Pour finir, je sais obtenir un retour a des performances normales en vidant le cache : sync ; echo 2 > /proc/sys/vm/drop_caches
(...)
J'ai utilisé "/proc/sys/vm/drop_caches" comme mot-clef dans Google. La ligne de commande que tu indiques demande au noyau de libérer la RAM qu'il avait allouée pour mettre en cache les fichiers et répertoires qu'il a lus.
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. La valeur affichée dans la colonne "cache" par la commande free ne prend en compte que le cache du contenu des fichiers, le "pagecache" et pas les caches de dentries et d'inodes. Le pagecache est vidé par la valeur 1. La valeur 3 vide les deux.
C'est très bizarre que ceci influence la vitesse de nos tableaux RAID car cette portion de RAM est supposée être réutilisable dès qu'un besoin réel se présente.
Et surtout, ces structures de données sont liées aux systèmes de fichiers montés et non aux périphériques bloc tels que les disques ou ensembles RAID.
En outre, sur une machine qui est actuellement coincée à des débits de 1 Mo/s, j'ai: ~>free -m total used free shared buff/cache available Mem: 7980 773 6125 172 1080 6278 Swap: 3813 0 3813 Sur 8 Go de RAM, plus de 6 Go sont disponibles. On ne peut pas qu'il y ait un manque.
Pour information, la mémoire occupée par les caches de dentries et d'inodes est comptée dans la colonne "used". Elle fait partie du "slab", dont on peut voir la taille dans /proc/meminfo et le détail dans /proc/slabinfo (chercher les colonnes contenant "inode" et "dentry"). 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 - en écriture dans le système de fichiers - 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) - même chose dans une partition classique non RAID - même chose avec d'autres types de systèmes de fichiers
Jean-Bernard Dubois
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. -- Cordialement Jean-Bernard Dubois Gaïa Converter
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.
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. -- Cordialement Jean-Bernard Dubois Gaïa Converter
