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
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
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
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
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,
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
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:
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
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
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 ?
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
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
(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
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,
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
* 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.
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
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
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
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
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
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
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
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
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 .
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
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.
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
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
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
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
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
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
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
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
-
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
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
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
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 ?
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
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
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
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
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
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,
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
- 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
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
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
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
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
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
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
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
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
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 à
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
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
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
60 matches
Mail list logo
