J'utilise Debian depuis une quinzaine d'années, sans problème de RAID
jusqu'à présent. Mon souci actuel est que deux machines qui font chacune
du RAID1 sur deux disques SSD ont des performances disque qui se dégradent
brutalement, sans raison apparente (rien trouvé dans syslog, notamment).
La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La
différence est si nette qu'une mesure grossière avec 'dd' suffit à la
mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=10000).
* La machine à la maison en a été la première victime, dès son
installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée en
janvier aussi). Le PC était neuf, ses disques aussi. (C'est toujours la
version stable de Debian que j'utilise.)
* La machine de bureau, qui donnait entière satisfaction depuis plusieurs
années, a commencé à montrer les mêmes symptômes juste après son passage de
Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce n'était pas
une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8 n'était que
partiellement à jour car j'utilise apt-get upgrade mais jamais dist-upgrade. La
version de Debian 8 sur la machine à la maison en janvier 2017 était donc en un
sens plus récente que la version de Debian 8 sur la machine de bureau en
juillet 2017.
* Par ailleurs, j'ai passé deux autres machines en Debian 9 sans rencontrer le
problème, mais elles font toutes deux du RAID6 sur des disques à plateaux.
* Les quatre machines utilisent exclusivement JFS.
Je souligne que même quand les performances deviennent abyssales, les tableaux
RAID fonctionnent. On peut par exemple copier un fichier ('cp').
Redémarrer la machine restaure la performance normale. La performance reste
alors stable pendant plusieurs heures. Puis elle s'écroule, ce qui peut
arriver même quand il n'y a personne devant l'écran, en pleine nuit.
Je joins ci-dessous le résultat des commandes suivantes, lancées sur la machine
de bureau (RAID1 sur sda+sdb):
smartctl -t short /dev/sda
smartctl -l selftest /dev/sda
smartctl -t short /dev/sdb
smartctl -l selftest /dev/sdb
Est-ce que ces comportements vous évoquent des souvenirs, ou des pistes à
creuser ? Comment pourrais-je extraire du système des informations sur
l'origine du problème ? Voyez-vous quels changements intervenus dans la
Debian 8, après la release initiale, pourraient causer ce comportement ?
Merci d'avance pour votre aide !
Seb.
PS: si quelqu'un sait comment régler le p'tit problème suivant, ça me sera
utile aussi: jusqu'à la Debian 8 incluse, quand je faisais un copier-coller
d'une ligne entière depuis un xterm vers un xterm exécutant zsh, la commande
s'exécutait dès l'étape coller. Depuis le passage à Debian 9, la commande
collée apparaît en inverse vidéo, un retour à la ligne a bien été inséré (le
curseur est sur une nouvelle ligne), mais cela ne provoque pas l'exécution de
la commande, il faut encore que j'appuie sur Entrée. J'aimerais bien revenir à
la situation précédente (pas besoin d'appuyer sur Entrée) mais je ne sais pas
ce qu'il faut régler...
#smartctl -l selftest /dev/sda
smartctl 6.6 2016-05-31 r4324 [i686-linux-4.9.0-3-686-pae] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours)
LBA_of_first_error
# 1 Short offline Completed without error 00% 17786 -
# 2 Short offline Completed without error 00% 15666 -
#smartctl -l selftest /dev/sdb
smartctl 6.6 2016-05-31 r4324 [i686-linux-4.9.0-3-686-pae] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours)
LBA_of_first_error
# 1 Short offline Completed without error 00% 16593 -
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-315536027-1507205745=:17980 Content-Type: TEXT/PLAIN; FORMAT=flowed; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: 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. ---1155178722-315536027-1507205745=:17980--
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
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.
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-315536027-1507205745=:17980 Content-Type: TEXT/PLAIN; FORMAT=flowed; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: 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. ---1155178722-315536027-1507205745=:17980--
Seb
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1905454995-1507207122=:17980 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT
* 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. ---1155178722-1905454995-1507207122=:17980--
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
* 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 ?)
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1905454995-1507207122=:17980 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT
* 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. ---1155178722-1905454995-1507207122=:17980--
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 ?
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 ?
(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 ?
Seb
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1018480088-1507208974=:17980 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID:
(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. ---1155178722-1018480088-1507208974=:17980--
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
(Je 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...
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1018480088-1507208974=:17980 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID:
(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. ---1155178722-1018480088-1507208974=:17980--
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 <https://en.wikipedia.org/wiki/Physical_Address_Extension> 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.
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
<https://en.wikipedia.org/wiki/Physical_Address_Extension>
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.
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 <https://en.wikipedia.org/wiki/Physical_Address_Extension> 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.
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).
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).
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).
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.
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.
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.
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
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.
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
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 <https://en.wikipedia.org/wiki/Physical_Address_Extension> 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
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
<https://en.wikipedia.org/wiki/Physical_Address_Extension>
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.
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 <https://en.wikipedia.org/wiki/Physical_Address_Extension> 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
Seb
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1534943101-1507640259=:24613 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT 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 mem500m lors du boot. Provisoirement, c'est un noyau 3.16 qui m'apporte le plus de confort. Seb. ---1155178722-1534943101-1507640259=:24613--
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
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 mem500m lors du boot. Provisoirement, c'est un noyau 3.16
qui m'apporte le plus de confort.
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1155178722-1534943101-1507640259=:24613 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT 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 mem500m lors du boot. Provisoirement, c'est un noyau 3.16 qui m'apporte le plus de confort. Seb. ---1155178722-1534943101-1507640259=:24613--
