#1 Le 09/01/2019, à 18:55
- Arbiel
[Résolu] Performances désastreuses de la 18.04. Des solutions ?
Bonjour
Pour des raisons sans importance ici, j'ai dȗ rester jusqu'à récemment à la 14.04. La fin de vie de cette distribution approchant rapidement, j'ai décidé d'installer la 18.04, et j'ai choisi de le faire sur de nouvelles partitions. J'ai ensuite modifié le fichier /etc/fstab pour récupérer mes paramètres et mes données antérieurs.
Les performances de la 18.04 me paraissent si mauvaises que j'envisage d'abandonner Ubuntu afin de ne pas rester bloqué indéfiniment sur une distribution qui ne serait plus maintenue. Mais avant d'en arriver là, j'aimerais pouvoir analyser les informations de démarrage pour comprendre ce que peut bien faire mon PC pendant le démarrage ou recueillir des conseils sur les points que je dois vérifier.
J'utilise LVM. Ce que j'appelle partition doit être compris comme volume logique.
Il faut savoir que je chiffre la racine et /home. Pour des raisons qui me sont propres, j'installe /boot et /usr sur des partitions distinctes de /. Enfin, pour faciliter les réparations, j'ai également installé la 18.04 sur une partition non chiffrée, toutes données dans la partition système. C'est mon système de secours.
La durée du démarrage, le temps écoulé entre l'appui sur la touche retour en réponse au menu de grub et l'affichage de mon bureau, s'établit ainsi :
avec la 14.04, 38''
avec la 18.04 de secours, 50''
avec la 18.04, 2'44''
Les 12'' d'écart entre la 14.04 et la 18.04 de secours ne montrent pas le réel ralentissement dû à la 18.04 puisqu'il n'y a plus d'ouverture de partitions chiffrées.
Par contre, j'ai du mal à me résoudre à l'idée que la 18.04 opérationnelle soit si lente du seul fait de l'ouverture des partitions chiffrées et du montage de mes diverses partitions de données dans l'arborescence de mes fichiers (opérations qui ont lieu également avec la 14.04).
J'espère ne pas avoir à abandonner la 18.04, d'autant plus que, s'y j'en crois des informations que j'ai lues récemment, elle serait maintenue pendant 10 ans.
Merci d'avance pour vos conseils
Arbiel
Dernière modification par Arbiel (Le 12/01/2019, à 13:16)
Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.
Hors ligne
#2 Le 10/01/2019, à 01:23
- jamesbad000
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
Bonsoir.
Tu confirme que ce problème de perf ce n'est pas juste au démarrage ?
Et que globalement l'installation sans chiffrement a des performances normale au delà du démarrage ?
Tu sais quel type de chiffrement est utilisé ?
Que donnes :
sudo lshw -c processor -c memory
sudo lsblk -o size,name,fstype,label,mountpoint
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#3 Le 10/01/2019, à 08:39
- malbo
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
Les performances de la 18.04 me paraissent si mauvaises que j'envisage d'abandonner Ubuntu afin de ne pas rester bloqué indéfiniment sur une distribution qui ne serait plus maintenue.
Tu as réellement une autre distribution en vue ou bien c'est juste pour te défouler que tu balances ce genre de conneries.
Dernière modification par malbo (Le 10/01/2019, à 08:42)
Hors ligne
#4 Le 10/01/2019, à 15:05
- Arbiel
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
Bonjour
@jamesbad000
Merci pour ton intervention.
Il ne s'agit pas uniquement des performances au démarrage. Je constate également la dégradation des performances lorsque je saisis du texte dans une page web, que ce soit pour le forum ou pour ma messagerie en mode "web-mail" : l'écho de la saisie peut mettre plusieurs secondes avant d'apparaître, sans que cela ne soit cependant systématique.
Dans les autres situations, les performances sont plus difficile à évaluer, car je n'utilise pratiquement jamais mon PC avec des applications très gourmandes (multimédia, jeux. …).
Je n'utilise pas vraiment la 18.04 que j'ai appelée de secours pour travailler. Je ne sais donc pas comment elle se comporterait dans la saisie de texte avec firefox.
Pour chiffrer et initialiser mes volumes logiques, j'utilise une procédure telle que
nice dd if=/dev/urandom of=${part}_l bs=1M
cle=$(echo ${part} | grep -e "[^/]*$" -o)
nice dd if=/dev/urandom of=/home/.${cle} bs=512 count=1
sudo cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 --key-file /home/.${cle} ${part}_l
sudo cryptsetup luksOpen --key-file /home/.${cle} ${part}_l ${cle}
sudo mke2fs -L ${cle} -t ext4 /dev/mapper/${cle}
Je mémorise ensuite mes clés sur support amovible et les efface de mon /home.
J'ai exécuté les deux commandes que tu as demandées avec la 14.04 et la 18.04, en demandant la sortie des durées d'exécution. Je donne ci-dessous tout d'abord le résultat sur les durées, puis le résultat des commandes elles-mêmes
avec la 14.04
time sudo lshw -c processor -c memory
…
real 0m4.904s
user 0m3.636s
sys 0m0.105s
time sudo lsblk -o size,name,fstype,label,mountpoint
…
real 0m1.525s
user 0m0.045s
sys 0m0.096s
Avec la 18.04
time sudo lshw -c processor -c memory
…
real 0m2,358s
user 0m0,704s
sys 0m0,018s
time sudo lsblk -o size,name,fstype,label,mountpoint
…
real 0m0,095s
user 0m0,024s
sys 0m0,047s
À ce niveau, force est de constater que les temps de réponse de la 18.04 sont meilleurs, que ceux de la 14.04. Il convient cependant de remarquer que ces commandes ne font pas appel à des modules graphiques.
Ci-dessous le résultat des commandes
remi@remi-Vostro-3550:~$ time sudo lshw -c processor -c memory
*-cpu
description: CPU
produit: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
fabriquant: Intel Corp.
identifiant matériel: 4
information bus: cpu@0
version: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
numéro de série: To Be Filled By O.E.M.
emplacement: CPU 1
taille: 800MHz
capacité: 800MHz
bits: 64 bits
horloge: 100MHz
fonctionnalités: x86-64 fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid cpufreq
configuration: cores=2 enabledcores=1 threads=2
*-cache:0
description: L1 cache
identifiant matériel: 5
emplacement: L1-Cache
taille: 64KiB
capacité: 64KiB
fonctionnalités: internal write-back unified
*-cache:1
description: L2 cache
identifiant matériel: 6
emplacement: L2-Cache
taille: 512KiB
capacité: 512KiB
fonctionnalités: internal varies unified
*-cache:2
description: L3 cache
identifiant matériel: 7
emplacement: L3-Cache
taille: 3MiB
capacité: 3MiB
fonctionnalités: internal varies unified
*-memory
description: Mémoire Système
identifiant matériel: 1d
emplacement: Carte mère
taille: 4GiB
*-bank:0
description: DIMMProject-Id-Version: @(#) $Id$Report-Msgid-Bugs-To: POT-Creation-Date: 2009-10-08 14:02+0200PO-Revision-Date: 2015-09-02 17:06+0000Last-Translator: Lyonel Vincent <Unknown>Language-Team: MIME-Version: 1.0Content-Type: text/plain; charset=UTF-8Content-Transfer-Encoding: 8bitX-Launchpad-Export-Date: 2016-07-20 12:05+0000X-Generator: Launchpad (build 18147) [vide]
produit: Not Specified
fabriquant: Not Specified
identifiant matériel: 0
numéro de série: Not Specified
emplacement: DIMM_A
*-bank:1
description: SODIMM DDR3 Synchrone 1333 MHz (0,8 ns)
produit: M471B5273DH0-CH9
fabriquant: Samsung
identifiant matériel: 1
numéro de série: 43081F52
emplacement: DIMM_B
taille: 4GiB
bits: 64 bits
horloge: 1333MHz (0.8ns)
*-firmware
description: BIOS
fabriquant: Dell Inc.
identifiant matériel: 0
version: A12
date: 02/18/2014
taille: 64KiB
capacité: 1984KiB
fonctionnalités: mca pci upgrade shadowing escd cdboot bootselect socketedrom edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer int10video acpi usb zipboot biosbootspecification
real 0m4.904s
user 0m3.636s
sys 0m0.105s
remi@remi-Vostro-3550:~$ time sudo lsblk -o size,name,fstype,label,mountpoint
SIZE NAME FSTYPE LABEL MOUNTPOINT
465,8G sda
306M ├─sda1 ntfs multi_amorces
20G ├─sda2 ntfs win7pro
10G ├─sda3 vfat TRANSIT
435,5G └─sda4 LVM2_mem
2,5G ├─victor-root_l (dm-0) crypto_L
2,5G │ └─victor-root (dm-13) ext4 /
8G ├─victor-usr (dm-1) ext4 /usr
1G ├─victor-boot (dm-2) ext2 /boot
140G ├─victor-ouranos (dm-3) ext2 victor-ouranos
115G ├─victor-gumnon (dm-4) ext2 victor-gumnon /media/remi/victor-gum
7G ├─victor-psilos (dm-5) ext4 victor-psilos /media/remi/victor-psi
5G ├─victor-odos_l (dm-6) crypto_L
10G ├─victor-trophe (dm-7) ext4 victor-trophe
1G ├─victor-archos (dm-8) ext2 victor-archos
10G ├─victor-oikia_l (dm-9) crypto_L
1,5G ├─victor-var_l (dm-10)
10G ├─victor-home_l (dm-11) crypto_L
10G │ └─victor-home (dm-14) ext4 victor-home /home
10G └─victor-secours (dm-12) ext4
29,8G sdb
29,8G ├─sdb1 vfat SANDISK /media/remi/SANDISK
10M └─sdb2 ext2 .sandisk /media/remi/.sandisk
15G sdc
9G ├─sdc1 vfat TRANSCEND /media/remi/TRANSCEND
6G └─sdc2 ext4 .transcend /media/remi/.transcend
1024M sr0
real 0m1.525s
user 0m0.045s
sys 0m0.096s
remi@remi-Vostro-3550:~$
remi@remi-Vostro-3550:~$ time sudo lshw -c processor -c memory
*-cpu
description: CPU
produit: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
fabriquant: Intel Corp.
identifiant matériel: 4
information bus: cpu@0
version: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
numéro de série: To Be Filled By O.E.M.
emplacement: CPU 1
taille: 2898MHz
capacité: 3200MHz
bits: 64 bits
horloge: 100MHz
fonctionnalités: x86-64 fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts flush_l1d cpufreq
configuration: cores=2 enabledcores=1 threads=2
*-cache:0
description: L1 cache
identifiant matériel: 5
emplacement: L1-Cache
taille: 64KiB
capacité: 64KiB
fonctionnalités: internal write-back unified
configuration: level=1
*-cache:1
description: L2 cache
identifiant matériel: 6
emplacement: L2-Cache
taille: 512KiB
capacité: 512KiB
fonctionnalités: internal varies unified
configuration: level=2
*-cache:2
description: L3 cache
identifiant matériel: 7
emplacement: L3-Cache
taille: 3MiB
capacité: 3MiB
fonctionnalités: internal varies unified
configuration: level=3
*-memory
description: Mémoire Système
identifiant matériel: 1d
emplacement: Carte mère
taille: 4GiB
*-bank:0
description: DIMMProject-Id-Version: @(#) $Id$Report-Msgid-Bugs-To: PO-Revision-Date: 2016-09-03 00:48+0000Last-Translator: Lyonel Vincent <Unknown>Language-Team: MIME-Version: 1.0Content-Type: text/plain; charset=UTF-8Content-Transfer-Encoding: 8bitX-Launchpad-Export-Date: 2018-07-12 13:19+0000X-Generator: Launchpad (build 18719) [vide]
produit: Not Specified
fabriquant: Not Specified
identifiant matériel: 0
numéro de série: Not Specified
emplacement: DIMM_A
*-bank:1
description: SODIMM DDR3 Synchrone 1333 MHz (0,8 ns)
produit: M471B5273DH0-CH9
fabriquant: Samsung
identifiant matériel: 1
numéro de série: 43081F52
emplacement: DIMM_B
taille: 4GiB
bits: 64 bits
horloge: 1333MHz (0.8ns)
*-firmware
description: BIOS
fabriquant: Dell Inc.
identifiant matériel: 0
version: A12
date: 02/18/2014
taille: 64KiB
capacité: 1984KiB
fonctionnalités: mca pci upgrade shadowing escd cdboot bootselect socketedrom edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer int10video acpi usb zipboot biosbootspecification
real 0m2,358s
user 0m0,704s
sys 0m0,018s
remi@remi-Vostro-3550:~$ time sudo lsblk -o size,name,fstype,label,mountpoint
SIZE NAME FSTYPE LABEL MOUNTPOINT
169,4M loop0 squashfs /snap/gimp/94
105,7M loop1 squashfs /snap/gnucash-jz/25
86,9M loop2 squashfs /snap/core/4917
14,5M loop3 squashfs /snap/gnome-logs/45
13M loop4 squashfs /snap/gnome-characters/103
11,2M loop5 squashfs /snap/spider-solitaire/1
17,9M loop6 squashfs /snap/pdftk/9
89,5M loop7 squashfs /snap/core/6034
138,3M loop8 squashfs /snap/thunderbird/29
2,3M loop9 squashfs /snap/gnome-calculator/260
169,4M loop10 squashfs /snap/gimp/88
2,3M loop11 squashfs /snap/gnome-calculator/180
34,6M loop12 squashfs /snap/gtk-common-themes/818
107M loop13 squashfs /snap/gnucash-jz/43
169,4M loop14 squashfs /snap/gimp/83
45M loop15 squashfs /snap/core18/442
99,1M loop16 squashfs /snap/simple-scan/34
34,7M loop17 squashfs /snap/gtk-common-themes/319
140,7M loop18 squashfs /snap/gnome-3-26-1604/74
53,7M loop19 squashfs /snap/core18/536
53,7M loop20 squashfs /snap/core18/512
3,7M loop21 squashfs /snap/gnome-system-monitor/57
14,5M loop22 squashfs /snap/gnome-logs/37
140,9M loop23 squashfs /snap/gnome-3-26-1604/70
89,5M loop24 squashfs /snap/core/6130
3,7M loop25 squashfs /snap/gnome-system-monitor/51
13M loop26 squashfs /snap/gnome-characters/139
465,8G sda
306M ├─sda1 ntfs multi_amorces
20G ├─sda2 ntfs win7pro
10G ├─sda3 vfat TRANSIT
435,5G └─sda4 LVM2_member
2,5G ├─victor-root_l
│ crypto_LUKS
8G ├─victor-usr ext4
1G ├─victor-boot ext2
140G ├─victor-ouranos
│ ext2 victor-ouranos
115G ├─victor-gumnon
│ ext2 victor-gumnon /media/remi/victor-gumnon
7G ├─victor-psilos
│ ext4 victor-psilos /media/remi/victor-psilos
5G ├─victor-odos_l
│ crypto_LUKS
5G │ └─victor-odos
│ ext4 victor-odos /
10G ├─victor-trophe
│ ext4 victor-trophe /usr
1G ├─victor-archos
│ ext2 victor-archos /boot
10G ├─victor-oikia_l
│ crypto_LUKS
10G │ └─victor-oikia
│ ext4
1,5G ├─victor-var_l
10G ├─victor-home_l
│ crypto_LUKS
10G │ └─victor-home
│ ext4 victor-home /home
10G └─victor-secours
ext4
29,8G sdb
29,8G ├─sdb1 vfat SANDISK /media/remi/SANDISK
10M └─sdb2 ext2 .sandisk /media/remi/.sandisk
15G sdc
9G ├─sdc1 vfat TRANSCEND /media/remi/TRANSCEND
6G └─sdc2 ext4 .transcend /media/remi/.transcend
1024M sr0
real 0m0,095s
user 0m0,024s
sys 0m0,047s
remi@remi-Vostro-3550:~$
@malbo
Je ne vois pas ce que ton intervention, à mes yeux plutôt mal venue, apporte à la présente discussion. Ni ce qui peut expliquer l'aggressivité dont tu fais preuve.
Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.
Hors ligne
#5 Le 10/01/2019, à 15:09
- nam1962
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
LVM est un nid à emmerdes (plein de fils résolus par son abandon) Je ne sais pas si ça a un rapport avec tes soucis.
Dernière modification par nam1962 (Le 10/01/2019, à 15:31)
[ Modéré ]
Hors ligne
#6 Le 10/01/2019, à 15:34
- jamesbad000
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
Ok c'est du chiffrement aes et aes est bien détecté dans les fonctionnalité de ta cpu. Donc ça élimine à priori la piste d'un chiffrement matériel qui serait devenu logiciel...
Je n'utilise pas vraiment la 18.04 que j'ai appelée de secours pour travailler. Je ne sais donc pas comment elle se comporterait dans la saisie de texte avec firefox.
Il serait quand même utile de faire l'exercice de comparaison pour voir c'est la 18.04 qui de base ne va pas bien avec ton PC (moi h'ai 2 config en 18.04 qui fonctionne dont une sur un portable 2core avec 4go de presque 10 ans ) ou s'il y a un problème localisé à une configuration.
Evidemment vérifier si ta CPU ne tourne pas en boucle sur une tache quand tu as cette lenteur de navigateur ou si ta mémoire n'est pas saturée (commandes top et free)
Pour ce qui est du démarrage, je conseille de démarrer en retirant les options quite splash de la ligne kernel au niveau du menu grub et de noter sur quels messages il bloque le plus longtemps.
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#7 Le 10/01/2019, à 16:23
- Arbiel
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
Je vais continuer mes investigations et ferai part ici de mes constats. Cela me prendra vraisemblablement quelques jours.
Pour être tout à fait clair, je souhaite continuer à utiliser Ubuntu. Mais, si je ne peux résoudre ce problème de performances, je me verrai contraint d'envisager une autre solution, soit poursuivre "indéfiniment" avec la 14.04, soit m'orienter vers une distribution moins gourmande, variante Ubuntu ou autre.
LVM est un nid à emmerdes (plein de fils résolus par son abandon)
S'agit-il d'un abandon, disons officiel, de ce produit, ou l'abandon, par certains utilisateurs, qui aurait abouti à la disparition de difficultés auxquelles ces utilisateurs auraient été confrontés ?
Pour ma part, je n'envisage pas son abandon, tant j'apprécie les facilités de gestion qu'il procure, sauf à utiliser un autre produit qui proposerait les mêmes options, ou des options comparables. Je ne déplore qu'un problème avec ce produit. Après réveil, je ne peux pas ouvrir de nouveaux volumes logiques, LVM ne retrouvant apparemment pas ses petits. Je dois alors redémarrer, et ouvrir ces volumes logiques avant de partir en veille. Situation suffisamment peu fréquente pour que je m'en accommode.
Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.
Hors ligne
#8 Le 10/01/2019, à 16:27
- nam1962
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
(...)
S'agit-il d'un abandon, disons officiel, de ce produit, ou l'abandon, par certains utilisateurs, qui aurait abouti à la disparition de difficultés auxquelles ces utilisateurs auraient été confrontés ?
(...)
Sur les fils que j'ai vu, la seconde option.
[ Modéré ]
Hors ligne
#9 Le 10/01/2019, à 16:30
- jamesbad000
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
J'ai ensuite modifié le fichier /etc/fstab pour récupérer mes paramètres et mes données antérieurs.
j'avais laissé ce point de coté. Mais j'ai tiqué la dessus !
Tu as repris intégralement tout ton répertoire perso avec les setup de la 14.04 ?
nam1962 a écrit :
LVM est un nid à emmerdes (plein de fils résolus par son abandon)
S'agit-il d'un abandon, disons officiel, de ce produit,
Non ça fonctionne. Mais c'est sur qu'on peut se retrouver dans des situations plus complexe qu'avec un partitionnement classique en cas d'incident. Donc quand on ne maîtrise pas assez bien le sujet et qu'en plus on n'a pas de sauvegarde c'est sur que ça doit mal se terminer.
Edit: une recherche de LVM dans le forum me donne 40 sujet donc 16 marqués résolus et un seul abandonné, le reste non qualifié.
Je fais la même avec GPT. sur 40 j'ai 15 résolus 0 abandonné... Conclusion c'est pas pire
Dernière modification par jamesbad000 (Le 10/01/2019, à 16:59)
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#10 Le 10/01/2019, à 22:05
- Arbiel
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
Bonsoir à tous
Tu as repris intégralement tout ton répertoire perso avec les setup de la 14.04 ?
Je voulais initialement bien séparer mes deux systèmes, mais je me suis un peu pris les pieds dans le tapis, de sorte que la réponse est affirmative. C'est peut-être aussi la raison de cet autre problème relatif à la 14.04 réinstallée après la 18.04.
Avant de poursuivre, je vais réinstaller la 14.04 et la 18.04 selon le principe que je voulais initialement suivre, à savoir l'indépendance totale entre les deux distributions. et cela dans de nouveaux volumes logiques. Je verrai ensuite comme récupérer le paramétrage de mes applications, et plus particulièrement ceux de firefox.
Je viendrai peut-être aussi présenter les difficultés que j'ai rencontrées et qui sont en rapport avec la situation présente.
J'en ai pour un moment, et je vous souhaite à tous le bonsoir.
Arbiel
Dernière modification par Arbiel (Le 11/01/2019, à 11:00)
Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.
Hors ligne
#11 Le 10/01/2019, à 22:19
- jamesbad000
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
Avant de poursuivre, je vais réinstaller la 14.04 et la 18.04
(...)
Je verrai ensuite comme récupérer le paramétrage de mes applications, et plus particulièrement ceux de firefox.
Tu fais bien Parce que franchement dans le cas contraire je ne dépenserais pas un neurone de plus à chercher dans une situation ou le paramétrage de l'environnement gnone / kde ou autre est repris tel quel.
Firefox, thunderbird par contre ça passe tout seul.
voir Gestion des Profils ici https://doc.ubuntu-fr.org/firefox#gestion_des_profils
Dernière modification par jamesbad000 (Le 10/01/2019, à 22:40)
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#12 Le 11/01/2019, à 00:58
- jamesbad000
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
En fait nul besoin de refaire tes installation pour ce problème de paramètres de profil utilisateur.
Dans chaque distrib après démarrage en mode recovery ou depuis un autre profil avec droits admin :
Supprimer le profil et son répertoire (deluser --remove-homel).
Puis le recréer (adduser)
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#13 Le 11/01/2019, à 01:28
- GammaDraconis
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
avec la 14.04, 38''
avec la 18.04 de secours, 50''
avec la 18.04, 2'44''
Même en 14.04 ton score est médiocre, moi je démarre en 8 secondes pour Ubuntu 18.04 et 5 secondes pour Archlinux.
Ton PC est assez peu puissant :
- vieux i5 de 2ème génération (actuellement on est à la 8eme génération, bientôt 9ème)
- seulement 4 Go de ram
- disque dur mécanique, probablement à 5400 tr/min sinon tu prendrai moins de 38 secondes
Désolé mais sur ta config, je ne recommande pas Ubuntu, c'est pas la 18.04 le problème, tu as des variantes plus légères en 18.04 et il y a aussi de nombreuses autres distributions linux ne l'oublie pas.
Ensuite n'oublie pas qu'il n'y a qu'une partition de chiffré (je sais pas si tu as séparé le home ou pas en faite si tu as des documents confidentiels, change de méthode : ne chiffre pas entièrement le disque dur, créer un lecteur chiffré avec par exemple VeraCrypt et tu places tes documents sensibles dans ce lecteur chiffré, c'est ce que j'utilise.
Cependant si tu as vraiment beaucoup de chose confidential (genre si tu es un chercheur en laboratoire qui travail sur un projet sensible), le mieux c'est de tout effacer ton disque dur et de créer une partition unique chiffré (pas divisé en plusieurs partitions). Biensûr en tant normale c'est mieux de séparer mais pas dans le cas de chiffrement du disque.
Discussion sur mon script de post-install pour Ubuntu 20.04LTS : https://forum.ubuntu-fr.org/viewtopic.php?id=2026344
Lien direct script : https://github.com/simbd/Ubuntu_20.04LTS_PostInstall
Démo vidéo (peertube) : https://video.ploud.fr/videos/watch/fb7 … 0d252ed2db
Hors ligne
#14 Le 11/01/2019, à 02:24
- Coeur Noir
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
Firefox → pourquoi pas utiliser la fonction de synchro, avec un compte chez Mozilla ( c'est chiffré ) ?
Tu peux mettre en commun des « documents » entre plusieurs distributions, mais pas les fichiers de config' ( cachés, dans le répertoire personnel de chaque utilisateur ).
Il y a un souci avec le lien du #11 ?
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#15 Le 11/01/2019, à 02:34
- moko138
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
Je voulais initialement bien séparer mes deux systèmes, mais je me suis un peu pris les pieds dans le tapis, de sorte que la réponse est affirmative. C'est peut-être aussi la raison de cet autre problème relatif à la 14.04 réinstallée après la 18.04.
Tu voulais dire ./viewtopic.php?id=2035298, non ?
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#16 Le 11/01/2019, à 03:06
- Roschan
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
Je suis à peu près certain que, quelle que soit la fiabilité de LVM, c'est par nature forcément plus lent, que ce soit au démarrage ou à l'utilisation ; surtout si tout est chiffré.
Pour évaluer ce qui prend du temps au démarrage :
systemd-analyze blame
Ou, pour un truc un peu plus complet et visuel :
systemd-analyze plot > boot_graph.svg
Hors ligne
#17 Le 12/01/2019, à 00:30
- Arbiel
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
Bonsoir à tous
Je vous remercie pour vos nombreuses interventions, auxquelles je ne répondrai peut-être pas à toutes, ce dont je vous prie, les uns et les autres de bien vouloir m'excuser.
Je crois avoir trouvé l'origine de ces piètres performances. J'ai ainsi pu abaisser à environ 1' la durée du démarrage, et surtout, ma saisie reste fluide. Les blocages lors de mes saisies sous firefox, comme c'est le cas présentement, ont été la principale raison de l'ouverture de cette discussion. J'ai mentionné la durée du démarrage dans les trois circonstances dans lesquelles je pouvais me trouver parce que je pouvais facilement les chronométrer, et qu'elles montraient clairement le problème.
La raison du problème est le chiffrement, plus exactement la manière dont l'ouverture des volumes logiques est traitée lors du démarrage.
Le fait d'avoir potentiellement mélangé des procédures incompatibles en partageant sans précautions mon espace personnel entre deux versions successives d'un même système n'y est apparemment pas pour grand chose. Cependant, j'ai réinstallé la 18.04 sur de nouveaux volumes logiques pour m'assurer de la propreté de mon système, mais c'est avec la 18.04 potentiellement endommagée que j'écris ma présente réponse.
Comme vous n'êtes pas forcément intéressés par mes points de vue, je présenterai le résultat de mes analyses dans ma prochaine réponse pour permettre à ceux qui le désirent de s'y reporter directement.
Bien sûr, comme certains d'entre vous me l'ont fait remarquer, l'empilement de LVM et du chiffrement ne peut que nuire aux performances et éventuellement à la fiabilité du système puisqu'il en est plus complexe. Cependant, je ne changerai pas ma manière de voir, du moins je ne vois actuellement aucune raison qui puisse me pousser à la changer.
LVM est un outil nettement plus confortable dans la gestion, disons des partitions, que la gestion classique par gparted. Il est vrai que mon PC, qui prend de l'âge, mais dont je n'ai aucune envie de me séparer, n'est pas un foudre de guerre. Il ne connaît pas l'UEFI. Pour la plupart d'entre vous, je suppose, vous avez en mémoire de la lourdeur de gestion de la partition étendue et des partitions secondaires sans que j'aie à y revenir. Je pense que même avec GPT/UEFI agrandir une partition coincée de part et d'autre entre deux partitions ne doit pas être une sinécure.
Pour ce qui est du chiffrement, mes raisons sont plus problématiques et peuvent paraître répondre à la question de savoir pourquoi il conviendrait de faire simple quand on peut faire compliqué.
Globalement, je considère que nous, les internautes, ne prenons pas assez au sérieux la défense de notre vie privée. Je reconnais que la messagerie électronique représente le risque le plus sérieux, mis à part les services tels que Facebook, que j'exécre. Mais on ne peut pas déplorer une situation si l'on essaie pas soi-même de s'en extraire. C'est ce qui m'a incité à opter pour la messagerie de Protonmail, comme ma signature l'indique. C'est la raison essentielle pour laquelle je chiffre mes volumes logiques et sans laquelle je ne pourrais pas écrire ce qui suit.
À cela s'ajoute, dans mon cas personnel, l'existence dans la Nièvre, du côté de Nevers, d'un chauffard prénommé et nommé comme moi, et qui a eu l'indélicatesse de naître le même jour, du même mois et de la même année que moi. Pour ce qui est de l'instant précis dans la journée, je ne sais pas. Il ne s'agit pas d'une usurpation d'identité, je suis aussi coupable que lui. Je n'ai pas payé ses amendes, mais c'est sur mon permis de conduire que ses points ont été retirés. Ceci n'est qu'une anecdote.
Il est temps maintenant de passer à la suite.
Arbiel
Dernière modification par Arbiel (Le 12/01/2019, à 13:10)
Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.
Hors ligne
#18 Le 12/01/2019, à 00:32
- Arbiel
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
Pour obtenir les performances actuelles, que je trouve acceptables, j'ai dû commenter les lignes du fichier /etc/crypttab pour en annuler les effets.
La manière dont le système doit ouvrir les volumes chiffrés est décrite dans ce fichier. Chaque volume y est répertorié par quatre champs, le nom, qui sert à créer le volume virtuel /dev/mapper/nom, la référence au volume chiffré, par exemple par son UUID, l'adresse éventuelle du fichier qui contient la clé de chiffrement et une liste d'options.
Il est utilisé tout d'abord pour la création ou la mise à jour de l'initrd, chargé entre autres de l'ouverture de la partition racine si celle-ci est chiffrée, puis lors du démarrage, pour l'ouverture des autres partitions chiffrées. Après le démarrage, il est également utilisé par la commande cryptdisks_start que l'utilisateur peut invoquer pour ouvrir d'autres partitions chiffrées inutilisées au démarrage. Dans ce cas, pour éviter l'ouverture automatique par le système, il convient d'utiliser l'option "noauto" dans la liste des options.
L'utilisateur peut également ouvrir des partitions chiffrées sans passer par le fichier /etc/crypttab, en utilisant la fonction cryptsetup.
Dans mon cas, les clés de chiffrement sont enregistrées sur une clé USB. Il se trouve que, pour des raisons hors sujet, grub, absent de mon disque dur, est lui aussi présent sur cette même clé, qui doit donc être branchée dès la mise sous tension, et reste présente tout au long du démarrage.
Jusqu'à la 14.04, initrd ouvrait la seule racine, laissant au système le soin d'ouvrir les autres partitions énumérées dans /etc/crypttab.
Depuis la 16.04, ou peut-être un peu avant elle (je n'installe que les LTS), c'est initrd qui est censé ouvrir toutes ces partitions. Ou plutôt, le système ne les ouvre plus. Cela simplifie indiscutablement la gestion du montage par fstab dans la mesure où toutes les partitions nécessaires ayant été montées par initrd, il n'y a plus à les attendre pour traiter les montages qui pourraient en dépendre.
Mais pour que initrd ouvre ces partitions, il faut que les lignes correspondantes de crypttab contiennent une nouvelle option, "initramfs". On peut raisonnablement se demander pourquoi il a fallu ajouter cette option alors qu'il est évident que, si une partition autre que la racine est mentionnée dans le fichier /etc/crypttab sans l'option "noauto", cela signifie que l'utilisateur désire l'ouvrir automatiquement au démarrage, sans avoir à se soucier de savoir qui fait quoi, initrd ou système, sauf à bien comprendre sous quelles conditions il lui convient de mettre à jour l'initrtd.
Lorsque j'ai installé la 16.04, j'ignorais totalement cette nouvelle procédure. Lorsque j'ai démarré mon PC, le système n'a pas pu monter les volumes virtuels correspondant aux partitions chiffrées puisqu'ils n'avaient pas été créés. Je me suis trouvé bloqué. Les traces m'ont appris que le système attendait la détection du volume support de mes clés de chiffrement, ce qui m'était incompréhensible puisque, par construction, ce volume était présent. J'ai alors abandonné la 16.04 en espérant qu'avec la 18.04 tout rentrerait dans l'ordre. Ce qui n'a pas été le cas.
L'installation de la 18.04 a abouti au même résultat, mais avec la nécessité, certes relative, de trouver une solution pour éviter de poursuivre avec une version arrivée en fin de vie.
J'ai tout d'abord pris connaissance de l'option initramfs par la relecture de la page du manuel relative à crypttab.
J'ai ensuite été bloqué par l'incapacité pour le système d'installation embarqué dans le fichier iso de créer l'initrd. J'ai résolu le problème en installant une 18.04 sans chiffrement sur une seule partition, mon système de secours évoqué au #1, la 14.04 étant incapable de traiter l'option initramfs et donc de créer l'initrd.
Après quoi, le système a bien voulu démarrer, mais avec les performances désastreuses qui m'ont amené à ouvrir la présente discussion.
Il se trouve que le système, bien que les volumes virtuels /dev/mapper/… aient été créés par l'initrd, attend la détection de ma clé USB, finit par se lasser et passe outre. Comme tout ce qui est nécessaire au démarrage est en place, il parvient à s'initialiser et ouvre ma session utilisateur.
L'introduction de l'option noauto ne résolvant apparemment pas le problème, j'ai annulé l'effet des lignes de crypttab en les commentant.
On est ainsi, sauf investigations supplémentaires que je n'ai pas le cœur de poursuivre, dans une situation où on ne peut pas créer l'initrd et lancer le système avec un fichier crypttab identique.
Il reste cependant le problème du blocage de ma saisie sous firefox, qui semble avoir disparu, mais dont je n'ai pas compris la raison.
Enfin, je travaille actuellement avec le système 18.04 "hybride", mais j'ai comme objectif de basculer sur la 18.04 bien propre que j'ai réinstallée ces derniers jours.
J'ai pris connaissance de vos diverses suggestions dont je n'ai encore tiré tous les enseignements, ce que je reporte à plus tard, compte tenu du temps consommé à venir à bout des difficultés présentées plus haut.
J'ai bien conscience d'avoir été un peu long avec toutes ces explications, et j'espère que vous ne m'en tiendrez pas grief.
Arbiel
Dernière modification par Arbiel (Le 12/01/2019, à 13:02)
Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.
Hors ligne
#19 Le 12/01/2019, à 13:21
- Arbiel
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
@malbo
Sans chercher à polémiquer, je te serais reconnaissant que tu m'expliques, éventuellement par message privé, ta réaction du #3.
Arbiel
Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.
Hors ligne
#20 Le 12/01/2019, à 14:19
- nam1962
Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?
Je comprends malbo et à te relire avec distance tu devrais aussi : ce type de phrase se trouve habituellement dans les fils de troll et il fallait te connaitre pour ne pas réagir de manière plus agacé
[ Modéré ]
Hors ligne