Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 09/01/2019, à 17: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, à 12: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, à 00: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, à 07:39

malbo

Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?

Arbiel a écrit :

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, à 07:42)

Hors ligne

#4 Le 10/01/2019, à 14: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, à 14: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, à 14:31)


[ Modéré ]

Hors ligne

#6 Le 10/01/2019, à 14: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, à 15: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.

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, 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, à 15:27

nam1962

Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?

Arbiel a écrit :

(...)
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, à 15:30

jamesbad000

Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?

Arbiel a écrit :

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 ?

Arbiel a écrit :

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, à 15: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, à 21:05

Arbiel

Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?

Bonsoir à tous

jamesbad000 a écrit :

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, à 10: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, à 21:19

jamesbad000

Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?

Arbiel a écrit :

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 smile 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, à 21: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 10/01/2019, à 23: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, à 00:28

GammaDraconis

Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?

Arbiel a écrit :

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, à 01: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ébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#15 Le 11/01/2019, à 01:34

moko138

Re : [Résolu] Performances désastreuses de la 18.04. Des solutions ?

Arbiel a écrit :

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, à 02: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 11/01/2019, à 23: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, à 12: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 11/01/2019, à 23: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, à 12: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, à 12: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, à 13: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é tongue


[ Modéré ]

Hors ligne