Re: Performance RAID instable

[Seb]

Merci Pascal pour les explications !


Pascal Hambourg (Fri, 20 Oct 2017):


Le 20/10/2017 à 09:10, Seb a écrit :



Pourquoi 4 Go ? C'est un peu arbitraire.
As-tu essayé d'autres valeurs entre 4 et 8 Go ?


Il me semble que le PAE permet au noyau d'utiliser la RAM au-delà de 4 Go:


Cette formulation est ambiguë.

PAE étend l'espace d'adressage en mémoire physique des processeurs 32 bits de 
4 Gio à 64 Gio. Mais cet espace ne contient pas que la RAM système. Il 
contient aussi les plages d'adresses des mémoires non volatiles du firmware 
de la carte mère et des périphériques internes comme la carte graphique, de 
la mémoire des mêmes périphériques permettant au système de transférer des 
données avec eux...


Le pseudo-fichier /proc/iomem recense les plages utilisées de l'espace 
mémoire physique.


Un système d'exploitation 32 bits sans PAE n'étant pas capable d'adresser 
au-delà de 4 Gio, toutes les plages autres que la RAM système doivent être 
accessibles à des adresses en-deça de cette limite. La plage d'adresse 
réservée aux périphériques est parfois appelée "PCI hole". Cela implique que 
la quantité de RAM système effectivement accessible à des adresses en-deça de 
4 Gio sera nécessairement inférieure à 4 Gio, typiquement de l'ordre de 3,5 
Go. Il ne faut pas confondre cette diminution avec la partie de la RAM 
système qui est réservée au GPU intégré.


La partie de la RAM système qui ne peut être adressée dans la plage en-deçà 
de 4 Gio est accessible à des adresses au-delà de 4 Gio donc uniquement par 
un système 32 bits avec PAE ou 64 bits.


Si par "au-delà de 4 Gio" tu voulais parler des adresses, alors oui. Mais si 
tu voulais parler de la quantité, alors non, la limite est plus basse 
notamment à cause du "PCI hole". Utiliser 4 Gio de RAM avec un système 32 
bits requiert PAE.


Je me suis dit que le noyau devait avoir des fonctions pour des RAM d'au 
plus 4 Go, et des astuces en plus pour les RAM au-delà, et que ce sont ces 
dernières qui sont actuellement buguées. Comme « ça marche », l'hypothèse a 
l'air correcte. Mais effectivement, non, je n'ai pas tenté 6 Go. Je ne vois 
pas de raison pour que ça marche.


PAE n'est pas juste une fonction qu'on active uniquement pour accéder aux 
adresses mémoire au-delà de 4 Gio. C'est une réorganisation permanente de la 
façon d'accéder à la mémoire physique. Avec un noyau PAE, les mécanismes de 
PAE sont à l'oeuvre quelle que soit la quantité de mémoire utilisable ou 
utilisée.


Bref, tout ça pour dire que la limite de 4 Gio de RAM que tu as fixée est 
arbitraire du point de vue de PAE car elle est déjà supérieure à la quantité 
utilisable sans PAE.


Par contre je me rappelle un commentaire de Linus Torvalds il y a déjà fort 
longtemps disant en substance qu'au-delà de 8 Gio de RAM, il valait mieux 
utiliser un noyau 64 bits car la gestion d'une telle quantité de mémoire par 
un noyau 32 bits avec PAE risquait d'être moins performante. Il ne faut pas 
oublier que même avec PAE l'espace d'adressage en mémoire virtuelle reste 
limité à 4 Gio, et l'espace réservé au noyau dans celui-ci à 1 Gio (3 Gio 
pour le processus).

Re: Performance RAID instable

[Pascal Hambourg]

Le 20/10/2017 à 09:10, Seb a écrit :



Pourquoi 4 Go ? C'est un peu arbitraire.
As-tu essayé d'autres valeurs entre 4 et 8 Go ?


Il me semble que le PAE permet au noyau d'utiliser la RAM au-delà de 4 Go:


Cette formulation est ambiguë.

PAE étend l'espace d'adressage en mémoire physique des processeurs 32 
bits de 4 Gio à 64 Gio. Mais cet espace ne contient pas que la RAM 
système. Il contient aussi les plages d'adresses des mémoires non 
volatiles du firmware de la carte mère et des périphériques internes 
comme la carte graphique, de la mémoire des mêmes périphériques 
permettant au système de transférer des données avec eux...


Le pseudo-fichier /proc/iomem recense les plages utilisées de l'espace 
mémoire physique.


Un système d'exploitation 32 bits sans PAE n'étant pas capable 
d'adresser au-delà de 4 Gio, toutes les plages autres que la RAM système 
doivent être accessibles à des adresses en-deça de cette limite. La 
plage d'adresse réservée aux périphériques est parfois appelée "PCI 
hole". Cela implique que la quantité de RAM système effectivement 
accessible à des adresses en-deça de 4 Gio sera nécessairement 
inférieure à 4 Gio, typiquement de l'ordre de 3,5 Go. Il ne faut pas 
confondre cette diminution avec la partie de la RAM système qui est 
réservée au GPU intégré.


La partie de la RAM système qui ne peut être adressée dans la plage 
en-deçà de 4 Gio est accessible à des adresses au-delà de 4 Gio donc 
uniquement par un système 32 bits avec PAE ou 64 bits.


Si par "au-delà de 4 Gio" tu voulais parler des adresses, alors oui. 
Mais si tu voulais parler de la quantité, alors non, la limite est plus 
basse notamment à cause du "PCI hole". Utiliser 4 Gio de RAM avec un 
système 32 bits requiert PAE.


Je me suis dit que le noyau devait avoir des fonctions pour des RAM d'au 
plus 4 Go, et des astuces en plus pour les RAM au-delà, et que ce sont 
ces dernières qui sont actuellement buguées. Comme « ça marche », 
l'hypothèse a l'air correcte. Mais effectivement, non, je n'ai pas tenté 
6 Go. Je ne vois pas de raison pour que ça marche.


PAE n'est pas juste une fonction qu'on active uniquement pour accéder 
aux adresses mémoire au-delà de 4 Gio. C'est une réorganisation 
permanente de la façon d'accéder à la mémoire physique. Avec un noyau 
PAE, les mécanismes de PAE sont à l'oeuvre quelle que soit la quantité 
de mémoire utilisable ou utilisée.


Bref, tout ça pour dire que la limite de 4 Gio de RAM que tu as fixée 
est arbitraire du point de vue de PAE car elle est déjà supérieure à la 
quantité utilisable sans PAE.


Par contre je me rappelle un commentaire de Linus Torvalds il y a déjà 
fort longtemps disant en substance qu'au-delà de 8 Gio de RAM, il valait 
mieux utiliser un noyau 64 bits car la gestion d'une telle quantité de 
mémoire par un noyau 32 bits avec PAE risquait d'être moins performante. 
Il ne faut pas oublier que même avec PAE l'espace d'adressage en mémoire 
virtuelle reste limité à 4 Gio, et l'espace réservé au noyau dans 
celui-ci à 1 Gio (3 Gio pour le processus).

Re: Performance RAID instable

[Seb]

Bonjour,


Il y a un détail qui m'interpelle. Pourquoi la gestion mémoire avec PAE 
n'impacte (apparement) que le système RAID logiciel du noyau ?


Chez moi seuls les tableaux RAID étaient affectés mais... je n'utilise que 
du RAID. D'autres ont signalé le même problème sur des disques isolés et 
même avec un clef USB. C'est donc seulement ma présentation qui donnait 
cet angle RAID (je pensais que le problème pouvait provenir de la gestion 
du RAID, idée plus immédiate que la gestion de la RAM).



Pourquoi 4 Go ? C'est un peu arbitraire.
As-tu essayé d'autres valeurs entre 4 et 8 Go ?


Il me semble que le PAE permet au noyau d'utiliser la RAM au-delà de 4 Go:
https://fr.wikipedia.org/wiki/Extension_d%27adresse_physique
Je me suis dit que le noyau devait avoir des fonctions pour des RAM d'au 
plus 4 Go, et des astuces en plus pour les RAM au-delà, et que ce sont ces 
dernières qui sont actuellement buguées. Comme « ça marche », l'hypothèse 
a l'air correcte. Mais effectivement, non, je n'ai pas tenté 6 Go. Je ne 
vois pas de raison pour que ça marche.



Seb.

Re: Performance RAID instable

[Pascal Hambourg]

Le 19/10/2017 à 16:06, Seb a écrit :


Merci beaucoup pour l'aide que vous m'avez apportée dans le diagnostic 
du problème. C'était bien un souci de gestion de la mémoire lié au PAE.


Sur la machine à la maison j'ai limité la RAM à 4 Go et depuis, la 
performance des disques est stable (980 Mo/s de moyenne).


Pourquoi 4 Go ? C'est un peu arbitraire.
As-tu essayé d'autres valeurs entre 4 et 8 Go ?

Re : Performance RAID instable

[Thierry Bugier]

Bonjour

Le jeudi 19 octobre 2017 à 16:06 +0200, Seb a écrit :
> Bonjour,
> 
> 
> Merci beaucoup pour l'aide que vous m'avez apportée dans le
> diagnostic du 
> problème. C'était bien un souci de gestion de la mémoire lié au PAE.
> 
> Sur la machine à la maison j'ai limité la RAM à 4 Go et depuis, la 
> performance des disques est stable (980 Mo/s de moyenne).
> 
> Sur la machine au bureau, 4 Go de RAM est trop juste pour InDesign
> dans 
> une VirtualBox alors j'ai réinstallé en amd64.
> 
> 
> Seb.

Il y a un détail qui m'interpelle. Pourquoi la gestion mémoire avec PAE
n'impacte (apparement) que le système RAID logiciel du noyau ?

Re: Performance RAID instable

[Seb]

Bonjour,


Merci beaucoup pour l'aide que vous m'avez apportée dans le diagnostic du 
problème. C'était bien un souci de gestion de la mémoire lié au PAE.


Sur la machine à la maison j'ai limité la RAM à 4 Go et depuis, la 
performance des disques est stable (980 Mo/s de moyenne).


Sur la machine au bureau, 4 Go de RAM est trop juste pour InDesign dans 
une VirtualBox alors j'ai réinstallé en amd64.



Seb.

Re: Performance RAID instable

[Seb]

Bonjour,


La semaine dernière, sur l'une des deux machines dont la performance 
disques est instable, j'avais installé un noyau 3.16. Le système a booté 
sans soucis, et depuis les chutes brutales et durables de performance ont 
cessé. J'ai uploadé un graphique:

https://framapic.org/2CBbZrCPNdnf/oQyFGaq0gACj.png

Au bruit près, la performance stable est d'environ 350 Mo/s. Cela permet 
de supposer qu'une génération suivante de noyaux a tenté d'optimiser la 
gestion de la mémoire (noyau 32 bits PAE), atteignant des vitesses de 
1000 Mo/s avec le même matériel, mais hélas cela conduisait à des 
« plantages » (chute vers < 1 Mo/s). La toute dernière version du noyau 
améliore un peu les choses, mais pas de manière décisive.


Il me reste à tester sur quelques jours le comportement d'un noyau 4.12 
avec la ligne mem=3500m lors du boot. Provisoirement, c'est un noyau 3.16 
qui m'apporte le plus de confort.



Seb.

Re: Performance RAID instable

[BERTRAND Joel]

Pascal Hambourg a écrit :

Le 05/10/2017 à 13:34, BERTRAND Joël a écrit :

 Je pense (mais je n'ai pas regardé, il y a longtemps que je ne
bidouille plus le noyau Linux) qu'avec moins de 4 Go de mémoire, même
avec PAE, le système ne va pas essayer de mapper la mémoire sur plus
de 32 bits d'adresses, donc n'essayera pas d'étendre l'adressage au-delà.


D'après ce que j'ai compris en lisant

l'activation de PAE modifie la structure des tables de pages (avec
notamment un niveau supplémentaire), quelle que soit la quantité de
mémoire physique à adresser. Je ne pense pas que le fait que la totalité
de la mémoire physique soit adressable avec 32 bits y change quelque chose.


	Personnellement, je ne fais pas d'hypothèse sur la complexité de la 
grouille rajoutée par PAE (j'ai des vieux souvenirs des problèmes de 
gestion de la mémoire sur sparc32 entre le 2.0 et le 2.2...). J'ai vu 
des trucs tellement ma fichus dans les noyaux Linux... D'autant que les 
noyaux i686 avec plus de 4Go de mémoire doivent être aujourd'hui 
marginaux. Je ne suis pas sûr qu'il y ait encore un réel effort là-dessus.


Cordialement,

JKB

Re: Performance RAID instable

[BERTRAND Joel]

Frédéric MASSOT a écrit :

Le 05/10/2017 à 11:12, BERTRAND Joël a écrit :

Seb a écrit :


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.)


Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire
ça, cela s'est soldé par un échec.


À cause du bug (865866) de LibreOffice Writer j'utilise un noyau 3.16
i386 sur une Buster avec systemd et udev sans problème. Il y a aucun
problème à changer de noyau.


Bonjour,

	Ça se fait, mais de là à dire sans problème... J'ai dû faire un 
rétrofit de matériel qui avait été installé avec un 4.x (j'ai oublié le 
numéro mineur). Le noyau 3.16 s'installe, boote, mais se baugeait lors 
de l'appel à udev et systemd. Il y a une dépendance forte entre udev, la 
version de la bouse systemd et celle du noyau. Ça peut se passer bien, 
avec juste une ligne de warning ou rien du tout, ça peut aussi mettre le 
système en vrac. On ne peut plus aujourd'hui garder des versions du 
noyau différentes pour se sortir d'un mauvais pas de manière fiable.


	Lorsque tu prends une Debian avec un 4.11 ou 4.12 et que tu veux 
remettre un 3.16, il convient d'installer toutes les dépendances du 
3.16. Et ça peut faire beaucoup de monde puisque de plus en plus 
d'outils tiers dépendent de la saloperie systemd.


	Dans le sens contraire, tu peux _aussi_ avoir des problèmes. Pas plus 
tard qu'hier, j'ai fait un dist-upgrade sur un serveur de test. 
Changement de noyau et, forcément, changement de udev et systemd. 
Impossible à redémarrer sans passer au bouton ! shutdown -r ne faisait 
rien (sauf bouffer 100% d'un CPU durant plus d'une heure). Le noyau 
initial était un 4.11, le nouveau un 4.12 avec la grouille qui venait 
avec lui. Là, ça allait, j'étais à côté de la machine. Mais je sens que 
je vais me déplacer pour mes machines hébergées qui n'ont pas de bandeau 
de prise commandé à distance.


Cordialement,

JKB

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 15:16, Seb a écrit :


Par contre, concernant le choix du noyau 3.16, pourquoi avoir choisi 
celui de wheezy-backports qui était adapté à l'userland de wheezy 
(déjà ancien et sans systemd) et n'est plus maintenu depuis la 
publication de jessie, plutôt que celui de jessie ?


Quand j'ai installé Jessie sur la machine de bureau, en 2015, je n'ai eu 
aucun problème avec le débit des disques.
Quand j'ai installé Jessie sur la machine à la maison, qui est presque 
un clone de la machine de bureau, en janvier 2017, le problème est 
apparu. À la même date, Jessie sur la machine de bureau, sur laquelle je 
fais des 'upgrade' mais jamais de 'dist-upgrade', fonctionnait sans 
problème.
Je fais donc l'hypothèse que le noyau a été mis à jour (sans changement 
du numéro de version) pendant la durée de vie de Jessie.


Je suis dubitatif sur cette hypothèse car un dist-upgrade n'est 
nécessaire pour mettre à jour le noyau qu'en cas de changement d'ABI, 
précisément parce que le nom des paquets du noyau, qui contient la 
version de l'ABI, change. Or d'après ce que je peux voir il n'y a pas eu 
de changement de la version d'ABI (4) du noyau 3.16 inclus dans Jessie 
depuis la publication initiale de Jessie. Donc un simple upgrade était 
suffisant pour installer toutes les mises à jour du noyau jusqu'à ce jour.

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 14:58, Frédéric MASSOT a écrit :


Il y a plusieurs années avec Lilo sur une machine physique où le mode
PAE ne fonctionnait pas bien, je limitais la mémoire à 3,7 ou 3,6 Go en
passant le paramètre mem= au noyau. La machine avait un problème avec le
PCI Hole.


Ce n'était probablement pas le PAE que ne fonctionnait pas bien mais le 
remapping de la mémoire physique masquée par le PCI hole au delà de la 
barrière de 4 Gio (et qui est donc inaccessible en 32 bits sans PAE).

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 13:34, BERTRAND Joël a écrit :

Pascal Hambourg a écrit :

Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)


 Et en recompilant depuis les sources quitte à recompiler en 32
bits sur un système 64 bits ?


Ou en activant le multi-arch et en installant les bibliothèques 32 bits
nécessaires ?


 Ça coule de source. Mais à force, ledit paquet risque de demander 
des bibliothèques qui ne seront plus sur les versions récentes de debian...


Certes mais si le .deb s'installe sur stretch i386, cela signifie que 
les dépendances nécessaires sont encore disponibles.



 Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau
d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une
complexité accrue.


Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne
désactivera pas PAE. C'est une option en dur dans le noyau. Pour
désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre
des fonctionnalités comme le NX/XD bit).


 Je pense (mais je n'ai pas regardé, il y a longtemps que je ne 
bidouille plus le noyau Linux) qu'avec moins de 4 Go de mémoire, même 
avec PAE, le système ne va pas essayer de mapper la mémoire sur plus de 
32 bits d'adresses, donc n'essayera pas d'étendre l'adressage au-delà.


D'après ce que j'ai compris en lisant

l'activation de PAE modifie la structure des tables de pages (avec 
notamment un niveau supplémentaire), quelle que soit la quantité de 
mémoire physique à adresser. Je ne pense pas que le fait que la totalité 
de la mémoire physique soit adressable avec 32 bits y change quelque chose.



Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un
mécanisme d'adressage à plusieurs niveaux dérivé de PAE.


 Ça ne dépend pas des options de compilation et des scripts 
d'édition des liens ? Il me semble qu'il est possible de forcer la 
taille des pointeurs dans ces scripts. Si tu force un adressage 64 bits 
réels, je ne vois pas ce qu'un mécanisme dérivé de PAE pourra bien venir 
faire là-dedans.


Le point commun, c'est l'utilisation de tables de pages avec des entrées 
sur 64 bits.

Re: Performance RAID instable

[Seb]

(Je vois bien la méthode facile et rapide pour descendre à 4 Go: 
enlever l'une des deux barrettes de RAM; comment feriez-vous si vous ne 
pouviez pas toucher au matériel ?)

En passant l'option mem=xxx à la ligne de commande du noyau.


Donc à la main lors du boot. OK.
(Oui bidouiller /etc/default/grub, noté.)

Par contre, concernant le choix du noyau 3.16, pourquoi avoir choisi 
celui de wheezy-backports qui était adapté à l'userland de wheezy (déjà 
ancien et sans systemd) et n'est plus maintenu depuis la publication de 
jessie, plutôt que celui de jessie ?


Quand j'ai installé Jessie sur la machine de bureau, en 2015, je n'ai eu 
aucun problème avec le débit des disques.
Quand j'ai installé Jessie sur la machine à la maison, qui est presque un 
clone de la machine de bureau, en janvier 2017, le problème est apparu. 
À la même date, Jessie sur la machine de bureau, sur laquelle je fais des 
'upgrade' mais jamais de 'dist-upgrade', fonctionnait sans problème.
Je fais donc l'hypothèse que le noyau a été mis à jour (sans changement du 
numéro de version) pendant la durée de vie de Jessie. Je sais que je ne 
veux pas la version du noyau qui était en vigueur dans Jessie juste avant 
la release de Stretch. Je ne sais pas laquelle des deux versions me 
donnerait le paquet linux-image-3.16.0-4-686-pae. Dans le doute, j'ai pris 
la version la plus ancienne que me proposait apt-get: 
linux-image-3.16.0-0.bpo.4-686-pae . Cela dit, s'il ne parle pas à 
systemd, ça va pas booter en Debian 9...



Seb.

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 14:38, Seb a écrit :


(Je vois bien la méthode facile 
et rapide pour descendre à 4 Go: enlever l'une des deux barrettes de 
RAM; comment feriez-vous si vous ne pouviez pas toucher au matériel ?)


En passant l'option mem=xxx à la ligne de commande du noyau.

Par contre, concernant le choix du noyau 3.16, pourquoi avoir choisi 
celui de wheezy-backports qui était adapté à l'userland de wheezy (déjà 
ancien et sans systemd) et n'est plus maintenu depuis la publication de 
jessie, plutôt que celui de jessie ?

Re: Performance RAID instable

[Frédéric MASSOT]

Le 05/10/2017 à 14:38, Seb a écrit :
> 
>> * Le problème ne se manifeste pas sur deux autres machines sous
>> Debian 9, qui ont pourtant le noyau 4.9.0-3-686-pae, signe que ce
>> n'est pas toute cette classe de noyaux qui pose problème.
> 
> Pardon, correction: je constate que ces deux machines (qui fonctionnent
> bien, elles) ont 2 Go de RAM. Du coup, l'hypothèse d'une RAM > 4 Go mal
> gérée dans les noyaux récents se trouve confortée.
> 
> Sur ma machine de bureau, je dois hélas régulièrement utiliser InDesign
> dans une VirtualBox: ça rame déjà affreusement, ça m'embêterait de ne
> pas disposer de 8 Go quand j'en ai besoin. Sur la machine à la maison,
> par contre, je pourrai sans problème descendre à 4 Go si le passage au
> noyau 3.16 ne se passe pas comme espéré. (Je vois bien la méthode facile
> et rapide pour descendre à 4 Go: enlever l'une des deux barrettes de
> RAM; comment feriez-vous si vous ne pouviez pas toucher au matériel ?)

Merci de ne pas me mettre en copie des mails je suis abonné à la liste.

Il y a plusieurs années avec Lilo sur une machine physique où le mode
PAE ne fonctionnait pas bien, je limitais la mémoire à 3,7 ou 3,6 Go en
passant le paramètre mem= au noyau. La machine avait un problème avec le
PCI Hole.

Aujourd'hui, tu peux ajouter "mem=3072m" à la ligne
"GRUB_CMDLINE_LINUX_DEFAULT=" du fichier "/etc/default/grub". Il faudra
tester avec plusieurs valeurs du seuil de la mémoire.


-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Performance RAID instable

[Seb]

* Le problème ne se manifeste pas sur deux autres machines sous 
Debian 9, qui ont pourtant le noyau 4.9.0-3-686-pae, signe que ce n'est 
pas toute cette classe de noyaux qui pose problème.


Pardon, correction: je constate que ces deux machines (qui fonctionnent 
bien, elles) ont 2 Go de RAM. Du coup, l'hypothèse d'une RAM > 4 Go mal 
gérée dans les noyaux récents se trouve confortée.


Sur ma machine de bureau, je dois hélas régulièrement utiliser InDesign 
dans une VirtualBox: ça rame déjà affreusement, ça m'embêterait de ne pas 
disposer de 8 Go quand j'en ai besoin. Sur la machine à la maison, par 
contre, je pourrai sans problème descendre à 4 Go si le passage au noyau 
3.16 ne se passe pas comme espéré. (Je vois bien la méthode facile et 
rapide pour descendre à 4 Go: enlever l'une des deux barrettes de RAM; 
comment feriez-vous si vous ne pouviez pas toucher au matériel ?)



Seb.

Re: Performance RAID instable

[Seb]

Bonjour,



Tu peux ajouter ces lignes dans le fichier "/etc/apt/sources.list" :
deb ftp://ftp.debian.org/debian/ wheezy-backports main contrib non-free
deb ftp://ftp.fr.debian.org/debian jessie main contrib non-free


Merci ! C'est ce que j'ai fait, Le package que je viens d'installer est
linux-image-3.16.0-0.bpo.4-686-pae
Par contre j'ai fait ça à distance si bien que je ne peux pas sélectionner 
aisément le noyau à utiliser par défaut lors du reboot; je testerai de 
visu ce soir pour valider que le système démarre correctement en 3.16 .



À propos de l'archi:

* Le problème ne se manifeste pas sur deux autres machines sous Debian 9, 
qui ont pourtant le noyau 4.9.0-3-686-pae, signe que ce n'est pas toute 
cette classe de noyaux qui pose problème.


* Avec le noyau initial de la Debian 8 (mais pas avec le noyau qui 
équipait l'ISO en janvier 2017), sur la même machine au bureau je n'avais 
aucun souci (8 Go RAM, noyau -686-pae).



À propos de gqview: oui, théoriquement je pourrais recompiler à partir des 
sources, en gardant des versions figées des bibliothèques, à la manière 
d'un snap. Mais pour l'instant, il suffit que j'accepte la légère pénalité 
de performance d'un noyau -686 par rapport à un noyau -amd pour pouvoir 
utiliser tel quel un ancien .deb; le compromis me va.



Seb.

Re: Performance RAID instable

[Frédéric MASSOT]

Le 05/10/2017 à 11:12, BERTRAND Joël a écrit :
> Seb a écrit :
>>
>> 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.)
> 
> Avec un init systemV, c'est assez trivial. Avec la grouille
> systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire
> ça, cela s'est soldé par un échec.

À cause du bug (865866) de LibreOffice Writer j'utilise un noyau 3.16
i386 sur une Buster avec systemd et udev sans problème. Il y a aucun
problème à changer de noyau.


-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Performance RAID instable

[BERTRAND Joël]

Pascal Hambourg a écrit :

Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :



Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)


 Et en recompilant depuis les sources quitte à recompiler en 32
bits sur un système 64 bits ?


Ou en activant le multi-arch et en installant les bibliothèques 32 bits
nécessaires ?


	Ça coule de source. Mais à force, ledit paquet risque de demander des 
bibliothèques qui ne seront plus sur les versions récentes de debian...



Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée


8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement
(VirtualBox).


 Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau
d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une
complexité accrue.


Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne
désactivera pas PAE. C'est une option en dur dans le noyau. Pour
désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre
des fonctionnalités comme le NX/XD bit).


	Je pense (mais je n'ai pas regardé, il y a longtemps que je ne 
bidouille plus le noyau Linux) qu'avec moins de 4 Go de mémoire, même 
avec PAE, le système ne va pas essayer de mapper la mémoire sur plus de 
32 bits d'adresses, donc n'essayera pas d'étendre l'adressage au-delà.



Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un
mécanisme d'adressage à plusieurs niveaux dérivé de PAE.


	Ça ne dépend pas des options de compilation et des scripts d'édition 
des liens ? Il me semble qu'il est possible de forcer la taille des 
pointeurs dans ces scripts. Si tu force un adressage 64 bits réels, je 
ne vois pas ce qu'un mécanisme dérivé de PAE pourra bien venir faire 
là-dedans.


Cordialement,

JKB

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :



    Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)


 Et en recompilant depuis les sources quitte à recompiler en 32 bits 
sur un système 64 bits ?


Ou en activant le multi-arch et en installant les bibliothèques 32 bits 
nécessaires ?



    Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée


8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).


 Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de 
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé 
plus de 4Go de mémoire (périphériques compris) au prix d'une complexité 
accrue.


Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne 
désactivera pas PAE. C'est une option en dur dans le noyau. Pour 
désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre 
des fonctionnalités comme le NX/XD bit).
Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un 
mécanisme d'adressage à plusieurs niveaux dérivé de PAE.

Re: Performance RAID instable

[BERTRAND Joël]

Seb a écrit :


Bonjour,



Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)


	Et en recompilant depuis les sources quitte à recompiler en 32 bits sur 
un système 64 bits ?



Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée


8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).


	Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de 
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé 
plus de 4Go de mémoire (périphériques compris) au prix d'une complexité 
accrue.



et le chipset (ou le contrôleur disque). C'est un point à ne pas
négliger d'autant que je vois pae dans le nom du noyau.


Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer
quelle serait la bonne commande ?


lspci par exemple.


  Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule.


J'aurais préféré rester en systemV, mais l'option n'est pas proposée
lors de l'installation de Debian et je ne sais pas dans quelle mesure on
peut espérer que Devuan et Debian resteront synchrones.


La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.


Aïe...


Bien cordialement,

JKB

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 11:12, BERTRAND Joël a écrit :

Seb a écrit :


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.)


 Avec un init systemV, c'est assez trivial. Avec la grouille 
systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire 
ça, cela s'est soldé par un échec.


Je l'avais fait quand Debian 9 stretch était encore en testing, peu 
avant sa publication en stable. Pas de problème particulier, sauf avec 
le GPU Radeon : en l'absence du firmware pourtant optionnel avec ce 
modèle de GPU, l'initialisation du module radeon semblait ne pas aller à 
son terme (il manquait des messages dans les logs du noyau) et 
l'affichage se coupait. Pourtant le même noyau 3.16 initialisait 
correctement le GPU même sans firmware avec le userland de Debian 8 
jessie. Le dernier message du module radeon dans les logs du noyau 
parlant de "user helper", il se peut fort bien que ce soit effectivement 
une incompatibilité avec la version de systemd/udev de stretch. Aucun 
problème en revanche si le firmware était présent, ni avec le noyau 4.9 
de stretch avec ou sans firmware.

Re: Performance RAID instable

[Frédéric MASSOT]

Le 05/10/2017 à 11:27, Seb a écrit :
> 
> Bonjour,
> 
> 
>> Une remarque en passant : je n'ai pas observé ce genre de chose en
>> amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
> 
> J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
> visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
> effacer des images si je laisse la touche Delete appuyée, ce qui
> m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
> un .deb mais il ne s'installe pas sur un système en 64 bits.)
> 
>> Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
>> installée
> 
> 8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
> 
>> et le chipset (ou le contrôleur disque). C'est un point à ne pas
>> négliger d'autant que je vois pae dans le nom du noyau.
> 
> Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer
> quelle serait la bonne commande ?

Tu peux utiliser lspci ou lshw.



-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Performance RAID instable

[Seb]

Bonjour,


	Une remarque en passant : je n'ai pas observé ce genre de chose en 
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le 
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien 
effacer des images si je laisse la touche Delete appuyée, ce qui m'arrive 
souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé un .deb 
mais il ne s'installe pas sur un système en 64 bits.)


	Je ne sais pas si tu as indiqué plus haut la taille de la mémoire 
installée


8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).

et le chipset (ou le contrôleur disque). C'est un point à ne pas 
négliger d'autant que je vois pae dans le nom du noyau.


Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer 
quelle serait la bonne commande ?



  Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule.


J'aurais préféré rester en systemV, mais l'option n'est pas proposée lors 
de l'installation de Debian et je ne sais pas dans quelle mesure on peut 
espérer que Devuan et Debian resteront synchrones.



La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.


Aïe...


Seb.

Re: Performance RAID instable

[BERTRAND Joël]

Seb a écrit :


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.)


	Avec un init systemV, c'est assez trivial. Avec la grouille 
systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire 
ça, cela s'est soldé par un échec.


JKB

Re: Performance RAID instable

[BERTRAND Joël]

Seb a écrit :


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


Bon...

	Une remarque en passant : je n'ai pas observé ce genre de chose en 
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).


	Je ne sais pas si tu as indiqué plus haut la taille de la mémoire 
installée et le chipset (ou le contrôleur disque). C'est un point à ne 
pas négliger d'autant que je vois pae dans le nom du noyau.


Cordialement,

JKB

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 10:40, Pascal Hambourg a écrit :


Sinon, faire comme avec les backports : ajouter les dépôts jessie dans 
sources.list et forcer l'installation du paquet de jessie avec apt-get 
-t jessie...


En fait même pas besoin de forcer puisque le paquet n'existe pas dans 
stretch.

Re: Performance RAID instable

[Frédéric MASSOT]

Le 05/10/2017 à 10:24, Seb a écrit :
> 
> 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 .

Les versions 3.16 sont dans les wheezy-backports et chez jessie :

https://packages.debian.org/search?suite=all=all=any=names=linux-image-3.16

Tu peux ajouter ces lignes dans le fichier "/etc/apt/sources.list" :

deb ftp://ftp.debian.org/debian/ wheezy-backports main contrib non-free
deb ftp://ftp.fr.debian.org/debian jessie main contrib non-free


Tu peux aussi ajouter l'ensemble des dépôts Wheezy et Jessie :

deb http://ftp.fr.debian.org/debian/ wheezy main contrib non-free
deb http://ftp.fr.debian.org/debian/ wheezy-updates main contrib non-free
deb http://security.debian.org/ wheezy/updates main contrib non-free
deb http://ftp.debian.org/debian/ wheezy-backports main contrib non-free

deb http://ftp.fr.debian.org/debian jessie main contrib non-free
deb http://security.debian.org/ jessie/updates main contrib non-free
deb http://ftp.fr.debian.org/debian jessie-updates main contrib non-free
deb http://ftp.fr.debian.org/debian/ jessie-backports main contrib non-free



-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Performance RAID instable

[Pascal Hambourg]

Le 05/10/2017 à 10:24, Seb a écrit :


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 ?

(...)
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.)


J'essaierais de récupérer directement le .deb du noyau 3.16 de Jessie 
depuis  
(je suppose que l'architecture est amd64) ou depuis une machine sous 
Jessie avec apt-get download et de l'installer avec dpkg -i sur Stretch. 
Les dépendances devraient être satisfaites.


Sinon, faire comme avec les backports : ajouter les dépôts jessie dans 
sources.list et forcer l'installation du paquet de jessie avec apt-get 
-t jessie...

Re : Performance RAID instable

[Seb]

Bonjour Thierry,


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.


C'est faisable. Tu me conseilles de contacter debian-kernel ou lkml ?


Seb.

Re: Performance RAID instable

[Seb]

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.

Re: Performance RAID instable

[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 ?

Re : Performance RAID instable

[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.

Re: Performance RAID instable

[Seb]

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.

Re: Performance RAID instable

[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.

Re: Performance RAID instable

[Seb]

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.

Re: Re : Re : Performance RAID instable

[Seb]

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.

Re : Re : Performance RAID instable

[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.

Re: Performance RAID instable

[BERTRAND Joël]

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

Re: Performance RAID instable

[Jean-Bernard Dubois]

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

--
Cordialement
Jean-Bernard Dubois
Gaïa Converter

Re: Re : Performance RAID instable

[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

Re: Performance RAID instable

[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

Re: Performance RAID instable

[Seb]

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
  totalusedfree  shared  buff/cache   available
Mem:   7980 7736125 1721080   6278
Swap:  3813   03813

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.

Re : Performance RAID instable

[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 ?

Re: Performance RAID instable

[Jean-Bernard Dubois]

Le 22/09/2017 à 12:22, Seb a écrit :


Bonjour !

Bonjour



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=1).
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.


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.


Comme toi j'utilise Debian depuis longtemps et je n'ai jamais eu de pb 
de disques ou de Raid. Je suis donc totalement ignorant sur le domaine 
et je ne sais pas expliquer ce qui ce passe.
En espérant avoir apporté un élément nouveau qui puisse aider a 
comprendre, je suis moi aussi avide d'une solution.


--
Cordialement
Jean-Bernard Dubois
Gaïa Converter

Re : Performance RAID instable

[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.

Re: Performance RAID instable

[bernard . schoenacker]

- Mail original -
> De: "Seb" <s...@h-k.fr>
> À: "Frederic MASSOT" <frede...@juliana-multimedia.com>
> Cc: debian-user-french@lists.debian.org
> Envoyé: Dimanche 24 Septembre 2017 15:42:25
> Objet: Re: Performance RAID instable
> 
> 
> 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.
> 
bonjour,

tu déposes ton image sur framadrop ou framapic et tu donnes
 le lien dans le courriel 


slt
bernard

Re: Performance RAID instable

[Seb]

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.

Re: Performance RAID instable

[Frederic MASSOT]

Le 22/09/2017 à 17:09, Seb a écrit :


Bonjour,


Les astuces que j'ai décrites permettent de maintenir les performances 
quand on écrit une grande quantité de données d'un coup ou bien une 
grandes quantité d'écritures aléatoirement réparties. C'est donné au 
cas où l'hypothèse que j'ai émise est la bonne, car ça colle très bien 
à ce que j'observe sur les supports amovibles. Reste à vérifier si 
l'architecture dont j'ai parlé est la même sur les SSD. J'irai jeter 
un oeil par curiosité.


La comparaison me paraît limitée: sur mon système, je peux copier des 
centaines de Mo sans aucun problème à pleine vitesse puis, une heure 
plus tard, alors qu'il ne se passe rien de particulier sur la machine, 
observer que mes disques SSD sont tout à coup devenus plus lents que ma 
connexion

ADSL.

Je serais tenté de tester les disques avec l'outil de diagnostic 
constructeur, spécifique aux SSD, si il existe (je suis resté sur les 
magnétiques pour le stockage de masse (je veux dire autre que l'OS)).


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 ?


--
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Performance RAID instable

[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.

Re: Performance RAID instable

[Pierre L.]

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 ?!

>> 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 ?
Linux = performances pourries
Windows = OK

>> 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 ;) "
Les échanges sont faits pour s'enrichir en connaissance !

>> 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 ?)

Merci pour les réponses agréables et les élagages de citations inutiles.
C'est toujours sympa d'être au contact des humains courtois et...
"humains" !
Bien à vous



signature.asc
Description: OpenPGP digital signature

Re: Performance RAID instable

[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

Re: Performance RAID instable

[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.

Re: Performance RAID instable

[Seb]

Hello,


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'. 
Je n'utilise aucune carte RAID.


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 ?


Je configure le RAID soft avec le partitionneur de Debian (version 
manuelle), lors de l'installation.



Seb.






Le 22/09/2017 à 17:09, Seb a écrit :


Bonjour,



Les astuces que j'ai décrites permettent de maintenir les
performances quand on écrit une grande quantité de données d'un coup
ou bien une grandes quantité d'écritures aléatoirement réparties.
C'est donné au cas où l'hypothèse que j'ai émise est la bonne, car ça
colle très bien à ce que j'observe sur les supports amovibles. Reste
à vérifier si l'architecture dont j'ai parlé est la même sur les SSD.
J'irai jeter un oeil par curiosité.


La comparaison me paraît limitée: sur mon système, je peux copier des
centaines de Mo sans aucun problème à pleine vitesse puis, une heure
plus tard, alors qu'il ne se passe rien de particulier sur la machine,
observer que mes disques SSD sont tout à coup devenus plus lents que
ma connexion
ADSL.


Je serais tenté de tester les disques avec l'outil de diagnostic
constructeur, spécifique aux SSD, si il existe (je suis resté sur les
magnétiques pour le stockage de masse (je veux dire autre que l'OS)).


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;

* j'observe la chose sur deux machines, dont une neuve.


D'ailleurs avec LVM ou RAID + hotswap ça peut se faire à chaud sans
période d'arrêt ou très courte.


Sous réserve d'avoir des disques SSD d'avance, ce qui n'est pas mon
cas...


Seb.




Le vendredi 22 septembre 2017 à 16:12 +0200, Seb a écrit :

Hello,



Les SSD prennent ils en charge TRIM ?


Oui.

~>sudo smartctl -i /dev/sda | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1
T0B/EU/
(^F TRIM)

(Je m'étais assuré de ce point quand j'avais acheté les disques.)

Je rappelle en outre que le même tableau RAID1 avec les mêmes disques
SSD
a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage
de
cette machine de Debian 8 à Debian 9.


L'effondrement de performance ne serait-il consécutif à une

écriture en

peu de temps de quelques centaines de Mo, ou bien de nombreuses
écritures très petites (< 32Ko environ) ?


Il m'arrive couramment de déplacer ou copier des centaines de Mo en
peu de
temps, mais ces moments ne coïncident pas avec la perte de
performance.
Des crontabs font des tas de jobs pour moi en sous-main, mais elles
les
faisaient aussi sous Debian 8.


Je n'utilise pas JFS, mais a t il été optimisé si possible pour
respecter les contraintes techniques de ce genre de support ?


J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des
disques
seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème
comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour
le
cas où quelqu'un aurait connaissance d'un changement dans la prise
en
charge de ce filesystem dans Debian, mais autrement, en lui-même, il
m'a
toujours semblé très solide.


Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout

cas

sur une clé USB bas de gamme ça fait des miracles.


Merci pour ces astuces d'optimisation. Mon problème est toutefois
inverse:
empêcher la chute soudaine et inexpliquée des performances, plutôt
que
tirer autant de débit que possible d'un système fonctionnant
correctement
à la base :-)


Seb.



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=1).

* 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 

Re: Performance RAID instable

[Pascal Hambourg]

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).

Re: Performance RAID instable

[Pierre L.]

Hello,
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"... 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. Ca sentait le "pilote" intégré à
Debian, selon mon avis par déduction absolument pas expert en la matière ;)
Peut-être suis-je complètement à coté de la plaque !!!

Après j'avoue que ca m'a toujours un peu perdu ces histoires de fakeraid...
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 ?



Le 22/09/2017 à 17:09, Seb a écrit :
>
> Bonjour,
>
>
>> Les astuces que j'ai décrites permettent de maintenir les
>> performances quand on écrit une grande quantité de données d'un coup
>> ou bien une grandes quantité d'écritures aléatoirement réparties.
>> C'est donné au cas où l'hypothèse que j'ai émise est la bonne, car ça
>> colle très bien à ce que j'observe sur les supports amovibles. Reste
>> à vérifier si l'architecture dont j'ai parlé est la même sur les SSD.
>> J'irai jeter un oeil par curiosité.
>
> La comparaison me paraît limitée: sur mon système, je peux copier des
> centaines de Mo sans aucun problème à pleine vitesse puis, une heure
> plus tard, alors qu'il ne se passe rien de particulier sur la machine,
> observer que mes disques SSD sont tout à coup devenus plus lents que
> ma connexion
> ADSL.
>
>> Je serais tenté de tester les disques avec l'outil de diagnostic
>> constructeur, spécifique aux SSD, si il existe (je suis resté sur les
>> magnétiques pour le stockage de masse (je veux dire autre que l'OS)).
>
> 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;
>
> * j'observe la chose sur deux machines, dont une neuve.
>
>> D'ailleurs avec LVM ou RAID + hotswap ça peut se faire à chaud sans
>> période d'arrêt ou très courte.
>
> Sous réserve d'avoir des disques SSD d'avance, ce qui n'est pas mon
> cas...
>
>
> Seb.
>
>
>>
>> Le vendredi 22 septembre 2017 à 16:12 +0200, Seb a écrit :
>>> Hello,
>>>
>>>
 Les SSD prennent ils en charge TRIM ?
>>>
>>> Oui.
>>>
>>> ~>sudo smartctl -i /dev/sda | grep ^"Device Model"
>>> Device Model: Samsung SSD 850 EVO 1TB
>>>
>>> ~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
>>> Device Model: Samsung SSD 850 EVO 1TB
>>>
>>> http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1
>>> T0B/EU/
>>> (^F TRIM)
>>>
>>> (Je m'étais assuré de ce point quand j'avais acheté les disques.)
>>>
>>> Je rappelle en outre que le même tableau RAID1 avec les mêmes disques
>>> SSD
>>> a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage
>>> de
>>> cette machine de Debian 8 à Debian 9.
>>>
 L'effondrement de performance ne serait-il consécutif à une
>>> écriture en
 peu de temps de quelques centaines de Mo, ou bien de nombreuses
 écritures très petites (< 32Ko environ) ?
>>>
>>> Il m'arrive couramment de déplacer ou copier des centaines de Mo en
>>> peu de
>>> temps, mais ces moments ne coïncident pas avec la perte de
>>> performance.
>>> Des crontabs font des tas de jobs pour moi en sous-main, mais elles
>>> les
>>> faisaient aussi sous Debian 8.
>>>
 Je n'utilise pas JFS, mais a t il été optimisé si possible pour
 respecter les contraintes techniques de ce genre de support ?
>>>
>>> J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des
>>> disques
>>> seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème
>>> comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour
>>> le
>>> cas où quelqu'un aurait connaissance d'un changement dans la prise
>>> en
>>> charge de ce filesystem dans Debian, mais autrement, en lui-même, il
>>> m'a
>>> toujours semblé très solide.
>>>
 Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout
>>> cas
 sur une clé USB bas de gamme ça fait des miracles.
>>>
>>> Merci pour ces astuces d'optimisation. Mon problème est toutefois
>>> inverse:
>>> empêcher la chute soudaine et inexpliquée des performances, plutôt
>>> que
>>> tirer autant de débit que possible d'un système fonctionnant
>>> correctement
>>> à la base :-)
>>>
>>>
>>> Seb.
>>>
>>>
> 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 

Re: Performance RAID instable

[Seb]

Bonjour,


Les astuces que j'ai décrites permettent de maintenir les performances 
quand on écrit une grande quantité de données d'un coup ou bien une 
grandes quantité d'écritures aléatoirement réparties. C'est donné au cas 
où l'hypothèse que j'ai émise est la bonne, car ça colle très bien à ce 
que j'observe sur les supports amovibles. Reste à vérifier si 
l'architecture dont j'ai parlé est la même sur les SSD. J'irai jeter un 
oeil par curiosité.


La comparaison me paraît limitée: sur mon système, je peux copier des 
centaines de Mo sans aucun problème à pleine vitesse puis, une heure plus 
tard, alors qu'il ne se passe rien de particulier sur la machine, observer 
que mes disques SSD sont tout à coup devenus plus lents que ma connexion

ADSL.

Je serais tenté de tester les disques avec l'outil de diagnostic 
constructeur, spécifique aux SSD, si il existe (je suis resté sur les 
magnétiques pour le stockage de masse (je veux dire autre que l'OS)).


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;


* j'observe la chose sur deux machines, dont une neuve.

D'ailleurs avec LVM ou RAID + hotswap ça peut se faire à chaud sans 
période d'arrêt ou très courte.


Sous réserve d'avoir des disques SSD d'avance, ce qui n'est pas mon cas...


Seb.




Le vendredi 22 septembre 2017 à 16:12 +0200, Seb a écrit :

Hello,



Les SSD prennent ils en charge TRIM ?


Oui.

~>sudo smartctl -i /dev/sda | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1
T0B/EU/
(^F TRIM)

(Je m'étais assuré de ce point quand j'avais acheté les disques.)

Je rappelle en outre que le même tableau RAID1 avec les mêmes disques
SSD
a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage
de
cette machine de Debian 8 à Debian 9.


L'effondrement de performance ne serait-il consécutif à une

écriture en

peu de temps de quelques centaines de Mo, ou bien de nombreuses
écritures très petites (< 32Ko environ) ?


Il m'arrive couramment de déplacer ou copier des centaines de Mo en
peu de
temps, mais ces moments ne coïncident pas avec la perte de
performance.
Des crontabs font des tas de jobs pour moi en sous-main, mais elles
les
faisaient aussi sous Debian 8.


Je n'utilise pas JFS, mais a t il été optimisé si possible pour
respecter les contraintes techniques de ce genre de support ?


J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des
disques
seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème
comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour
le
cas où quelqu'un aurait connaissance d'un changement dans la prise
en
charge de ce filesystem dans Debian, mais autrement, en lui-même, il
m'a
toujours semblé très solide.


Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout

cas

sur une clé USB bas de gamme ça fait des miracles.


Merci pour ces astuces d'optimisation. Mon problème est toutefois
inverse:
empêcher la chute soudaine et inexpliquée des performances, plutôt
que
tirer autant de débit que possible d'un système fonctionnant
correctement
à la base :-)


Seb.



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=1).

* 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 

Re : Re : Performance RAID instable

[Thierry Bugier]

Je ne reproche rien à JFS, sinon d'être populaire :)

Vu le modèle, c'est clair ils ont TRIM, plus aucun disque ne doit être
produit sans cette techno. 

Les astuces que j'ai décrites permettent de maintenir les performances
quand on écrit une grande quantité de données d'un coup ou bien une
grandes quantité d'écritures aléatoirement réparties. C'est donné au
cas où l'hypothèse que j'ai émise est la bonne, car ça colle très bien
à ce que j'observe sur les supports amovibles. Reste à vérifier si
l'architecture dont j'ai parlé est la même sur les SSD. J'irai jeter un
oeil par curiosité.

Je serais tenté de tester les disques avec l'outil de diagnostic
constructeur, spécifique aux SSD, si il existe (je suis resté sur les
magnétiques pour le stockage de masse (je veux dire autre que l'OS)). A
faire seulement si vous avez des disques fiables sur lesquels migrer la
grappe.

D'ailleurs avec LVM ou RAID + hotswap ça peut se faire à chaud sans
période d'arrêt ou très courte. 

Le vendredi 22 septembre 2017 à 16:12 +0200, Seb a écrit :
> Hello,
> 
> 
> > Les SSD prennent ils en charge TRIM ?
> 
> Oui.
> 
> ~>sudo smartctl -i /dev/sda | grep ^"Device Model"
> Device Model: Samsung SSD 850 EVO 1TB
> 
> ~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
> Device Model: Samsung SSD 850 EVO 1TB
> 
> http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1
> T0B/EU/
> (^F TRIM)
> 
> (Je m'étais assuré de ce point quand j'avais acheté les disques.)
> 
> Je rappelle en outre que le même tableau RAID1 avec les mêmes disques
> SSD 
> a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage
> de 
> cette machine de Debian 8 à Debian 9.
> 
> > L'effondrement de performance ne serait-il consécutif à une
> écriture en 
> > peu de temps de quelques centaines de Mo, ou bien de nombreuses 
> > écritures très petites (< 32Ko environ) ?
> 
> Il m'arrive couramment de déplacer ou copier des centaines de Mo en
> peu de 
> temps, mais ces moments ne coïncident pas avec la perte de
> performance. 
> Des crontabs font des tas de jobs pour moi en sous-main, mais elles
> les 
> faisaient aussi sous Debian 8.
> 
> > Je n'utilise pas JFS, mais a t il été optimisé si possible pour 
> > respecter les contraintes techniques de ce genre de support ?
> 
> J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des
> disques 
> seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème 
> comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour
> le 
> cas où quelqu'un aurait connaissance d'un changement dans la prise
> en 
> charge de ce filesystem dans Debian, mais autrement, en lui-même, il
> m'a 
> toujours semblé très solide.
> 
> > Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout
> cas 
> > sur une clé USB bas de gamme ça fait des miracles.
> 
> Merci pour ces astuces d'optimisation. Mon problème est toutefois
> inverse: 
> empêcher la chute soudaine et inexpliquée des performances, plutôt
> que 
> tirer autant de débit que possible d'un système fonctionnant
> correctement 
> à la base :-)
> 
> 
> Seb.
> 
> 
> >> 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=1).
> >>
> >> * 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 

Re: Re : Performance RAID instable

[Seb]

Hello,



Les SSD prennent ils en charge TRIM ?


Oui.

~>sudo smartctl -i /dev/sda | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1T0B/EU/
(^F TRIM)

(Je m'étais assuré de ce point quand j'avais acheté les disques.)

Je rappelle en outre que le même tableau RAID1 avec les mêmes disques SSD 
a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage de 
cette machine de Debian 8 à Debian 9.


L'effondrement de performance ne serait-il consécutif à une écriture en 
peu de temps de quelques centaines de Mo, ou bien de nombreuses 
écritures très petites (< 32Ko environ) ?


Il m'arrive couramment de déplacer ou copier des centaines de Mo en peu de 
temps, mais ces moments ne coïncident pas avec la perte de performance. 
Des crontabs font des tas de jobs pour moi en sous-main, mais elles les 
faisaient aussi sous Debian 8.


Je n'utilise pas JFS, mais a t il été optimisé si possible pour 
respecter les contraintes techniques de ce genre de support ?


J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des disques 
seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème 
comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour le 
cas où quelqu'un aurait connaissance d'un changement dans la prise en 
charge de ce filesystem dans Debian, mais autrement, en lui-même, il m'a 
toujours semblé très solide.


Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout cas 
sur une clé USB bas de gamme ça fait des miracles.


Merci pour ces astuces d'optimisation. Mon problème est toutefois inverse: 
empêcher la chute soudaine et inexpliquée des performances, plutôt que 
tirer autant de débit que possible d'un système fonctionnant correctement 
à la base :-)



Seb.



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=1).

* 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 

Re : Performance RAID instable

[Thierry Bugier]

Bonjour

Quelques questions:

Les SSD prennent ils en charge TRIM ?

L'effondrement de performance ne serait-il consécutif à une écriture en
peu de temps de quelques centaines de Mo, ou bien de nombreuses
écritures très petites (< 32Ko environ) ?

Je n'utilise pas JFS, mais a t il été optimisé si possible pour
respecter les contraintes techniques de ce genre de support ?

Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout cas
sur une clé USB bas de gamme ça fait des miracles.

Les stockages "solide" ou "flash" connaissent la notion de bloc
d'effacement. C'est à dire que quand on écrit une donnée on va modifier
sur un de ces blocs, si la donnée écrite diffère d'un seul bit du
contenu préalablement enregistré, il faut effacer tout le bloc et le
réécrire entièrement. Une exception, si les tous bits devant être
modifiés passent de l'état 0 à l'état 1 et pas l'inverse.

Donc pour un seul bit, on peut se retrouver à écrire en réalité un bloc
 de l'ordre du Mo. Du gâchis en somme. 

J'ai eu à utiliser une clé USB ces dernières semaines pour transférer
quelques Go d'un PC à un autre. En optimisant le système de fichiers
ext4 (la clé étatn une bouse de supermarché) j'ai ou atteindre un débit
entre 15 et 20 Mo/s. Au delà de mes espérances pour le support que
j'avais.

L'astuce consiste à configurer le système de fichier pour écrire par
blocs de taille multiple du bloc d'effacement.

Pour trouver la  taille de ce bloc d'effacement, trouvez dans les
dépôts Debian le paquet flashbench. Le site donne des infos sur
l'interprétation des résultats: https://github.com/bradfa/flashbench

En cherchant une source pour expliquer l'optimisation d'un support
flash (usb ou SD) je retrouve sur la source qui m'a tout appris. Je la
redonne donc ici : https://blogofterje.wordpress.com/2012/01/14/optimiz
ing-fs-on-sd-card/

Elle explique aussi l'alignement des partitions, et le "segment size"
dont j'ai oublié de parler.

Dans le cas d'un RAID, il faudra faire des configurations similaires au
niveau de la grappe. C'est paramétrable et à l'époque des disques
magnétiques on optimisait déjà les performances en configurant finement
ses grappes. Un vieil exemple : http://monblog.system-linux.net/blog/20
11/07/02/modification-de-lalignement-disque-lors-de-linstallation-dune-
mandriva-2009-0/

Encore une fois, il faut vérifier si ça s'applique aux SSD, je pense
que oui, mais sans avoir de preuve pour l'instant. Je n'ai pas eu de
problème particulier en me contentant d'aligner mes partitions (il
supporte TRIM).



Le vendredi 22 septembre 2017 à 12:22 +0200, Seb a écrit :
> Bonjour !
> 
> 
> 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=1).
> 
> * 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