Questions sur l'installation et la configuration de Manjaro Linux.
Répondre

Optimisation

#1Messageil y a 3 ans

Bonjour,

Je trouve mon système particulièrement "lent" au démarrage. Je suis passé depuis peu sur du SSD, et je trouve le temps de démarrage aussi long qu'avant.
En faisant des recherches sur le forum j'ai trouvé quelques sujets avec les commandes à lancer, mais après je ne sais pas les mesures à prendre pour corriger les problèmes.

systemd-analyze = 1min 16.768s

$ systemd-analyze
Startup finished in 15.048s (firmware) + 2.683s (loader) + 3.160s (kernel) + 55.876s (userspace) = 1min 16.768s 
graphical.target reached after 12.583s in userspace
systemd-analyze blame

$ systemd-analyze blame
44.980s man-db.service                                                                           
10.176s NetworkManager-wait-online.service                                                       
 9.496s systemd-journal-flush.service                                                            
 6.218s udisks2.service                                                                          
 5.504s org.cups.cupsd.service                                                                   
 1.768s colord.service                                                                           
 1.703s snapd.service                                                                            
 1.400s tlp.service                                                                              
 1.265s systemd-logind.service                                                                   
  881ms apparmor.service                                                                         
  653ms systemd-random-seed.service                                                              
  614ms logrotate.service                                                                        
  523ms upower.service                                                                           
  498ms lvm2-monitor.service                                                                     
  490ms NetworkManager.service                                                                   
  371ms dev-sda1.device
systemd-analyze critical-chain

$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @12.583s
└─multi-user.target @12.583s
  └─[b]snapd.service @10.879s +1.703s[/b]
    └─basic.target @10.870s
      └─sockets.target @10.869s
        └─[b]snapd.socket @10.868s +824us[/b]
          └─sysinit.target @10.864s
            └─[b]systemd-timesyncd.service @10.651s +213ms[/b]
              └─[b]systemd-tmpfiles-setup.service @10.623s +26ms[/b]
                └─[b]systemd-journal-flush.service @1.126s +9.496s[/b]
                  └─[b]var.mount @1.046s +73ms[/b]
                    └─[b]systemd-fsck@dev-disk-by\x2duuid-10bcaa5b\x2d6b5f\x2d45ca\x2dad8d\x2d86ef291b3823.service @706ms +337ms[/b]
                      └─local-fs-pre.target @705ms
                        └─[b]lvm2-monitor.service @207ms +498ms[/b]
                          └─lvm2-lvmetad.service @226ms
                            └─systemd-journald.socket @202ms
                              └─system.slice @192ms
                                └─-.slice @192ms
sda est un disque SSD, sdb est un disque dur
lsblk -o "NAME,UUID,LABEL,SIZE,TYPE,ROTA,FSTYPE,PARTTYPE,MOUNTPOINT"

$ lsblk -o "NAME,UUID,LABEL,SIZE,TYPE,ROTA,FSTYPE,PARTTYPE,MOUNTPOINT" 
NAME   UUID                                 LABEL   SIZE TYPE ROTA FSTYPE PARTTYPE                             MOUNTPOINT
sda                                               223,6G disk    0                                             
├─sda1 f2d8e9ff-9ffe-4eea-8667-8f9f07d818d9       223,3G part    0 ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 /
└─sda2 1C40-848A                                    300M part    0 vfat   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 /boot/efi
sdb                                               931,5G disk    1                                             
├─sdb1 10bcaa5b-6b5f-45ca-ad8d-86ef291b3823           5G part    1 ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 /var
├─sdb2 e7e19140-6576-4200-853a-b8c32b6f9bf4           5G part    1 ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 
├─sdb3 5fddf621-af91-41b5-afdd-5816a9b41222         8,8G part    1 swap   0657fd6d-a4ab-43c4-84e5-0933c84b4f4f [SWAP]
└─sdb4 95ac0f89-bec3-453c-9f93-367479266ec5       912,7G part    1 ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 /home
sr0                                                1024M rom     1 
fstab

$ cat /etc/fstab 
# /etc/fstab: static file system information.
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=1C40-848A                            /boot/efi      vfat    umask=0077 0 2
UUID=f2d8e9ff-9ffe-4eea-8667-8f9f07d818d9 /              ext4    defaults,noatime 0 1
UUID=10bcaa5b-6b5f-45ca-ad8d-86ef291b3823 /var           ext4    defaults,noatime 0 2
# UUID=e7e19140-6576-4200-853a-b8c32b6f9bf4 /tmp           ext4    defaults,noatime 0 2
UUID=95ac0f89-bec3-453c-9f93-367479266ec5 /home          ext4    defaults,noatime 0 2
UUID=5fddf621-af91-41b5-afdd-5816a9b41222 swap           swap    defaults,noatime 0 2
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
Comme vous pouvez le voir, j'ai mis la partition sdb3 qui pointait vers /tmp en commentaire car j'ai découvert qu'après "le système" avait ajouté une ligne pour créer un /tmp en mémoire (un bug ?).

Dans ce sujet d'optimisation, papajoke indique qu'il ne faut pas tenir compte de la ligne "man-db.service", pourtant, plus bas dans le sujet ewolnux affiche ses stats avec "1.249s man-db.service" ! Ça fait rêver.

Le deuxième gros temps concerne "10.176s NetworkManager-wait-online.service", pour une connexion Ethernet, pas de wifi, ni bluetooth dans cette machine. C'est quoi le problème ?

J'ai mis en place ce fichier /etc/systemd/journald.conf.d/limite.conf hier, l'effet devrait déjà être visible ou bien il faut attendre quelques jours ?

#créer un fichier /etc/systemd/journald.conf.d/limite.conf        
[Journal]
#niveau minimum à enregistrer
MaxLevelStore=notice
#taille max du fichier, pas obligatoire de sauvegarder 1 an ;)
SystemMaxUse=250M
Merci d'avance pour votre aide. :merci:

Optimisation

#2Messageil y a 3 ans

Bonjour.
Tu peux déjà lancer

sudo updatedb
systemctl stop NetworkManager-wait-online.service
sydtemctl disable NetworkManager-wait-online.service
reboot
La mise à jour de updatedb est silencieuse et peut être longue....
Il y a aussi snapd qui semble gourmand en ressource. Tu devrais ne l'activer que sur demande.
Ce qui m'étonne est Startup finished in 15.048s (firmware). As tu des partitions chiffrées (LUKS) ?

Optimisation

#3Messageil y a 3 ans

si tu n'as pas de volume logique
tu peux arrêter le service lvm2-monitor et ModemManager.service

sudo systemctl mask lvm2-monitor.service
sudo systemctl mask modemmanager.service
peux tu aussi fournir le retour de

cat /sys/block/sd*/queue/scheduler
pour les SSD le mettre a none et non mq-deadline
pour les HDD , en BFQ

reste la question d'apparmor , si tu utilise les snap ou pas
ainsi que la log du journal ,

sudo journalctl --disk-usage
je préconise

sudo journalctl --vacuum-size=1G
et conservation sur 1an , 365j

sudo journalctl --vacuum-time=365d

Optimisation

#4Messageil y a 3 ans

lemust83 a écrit : il y a 3 ans Tu peux déjà lancer

sudo updatedb
systemctl stop NetworkManager-wait-online.service
sydtemctl disable NetworkManager-wait-online.service
reboot
La mise à jour de updatedb est silencieuse et peut être longue....
Il y a aussi snapd qui semble gourmand en ressource. Tu devrais ne l'activer que sur demande.
Ce qui m'étonne est Startup finished in 15.048s (firmware). As tu des partitions chiffrées (LUKS) ?
mlocate n'était pas installé, c'est fait. Commandes lancées.
J'ai supprimé snap que je ne connaissais pas.
Pas de partition chiffrée.
stephane a écrit : il y a 3 ans si tu n'as pas de volume logique
tu peux arrêter le service lvm2-monitor et ModemManager.service

sudo systemctl mask lvm2-monitor.service
sudo systemctl mask modemmanager.service
peux tu aussi fournir le retour de

cat /sys/block/sd*/queue/scheduler
pour les SSD le mettre a none et non mq-deadline
pour les HDD , en BFQ

reste la question d'apparmor , si tu utilise les snap ou pas
ainsi que la log du journal ,

sudo journalctl --disk-usage
je préconise

sudo journalctl --vacuum-size=1G
et conservation sur 1an , 365j

sudo journalctl --vacuum-time=365d
Commandes systemctl mask lancées

$ cat /sys/block/sd*/queue/scheduler
[mq-deadline] kyber bfq none
[mq-deadline] kyber bfq none
c'est avec les crochets que l'on gère l'option choisie ? Donc sur la première ligne (ssd) je mets les crochets autour de none, et pour l'autre je mets les crochets autour de bfq ?

Comme indiqué plus haut, j'ai supprimé snap. AppArmor, que dois-je prendre en considération ?

$ sudo journalctl --disk-usage
Archived and active journals take up 224.0M in the file system.
Mais je lance quand même les commandes pour limiter à 256M et 180 jours.

Merci pour vos retours :)

Optimisation

#5Messageil y a 3 ans

Après le reboot

$ systemd-analyze
Startup finished in 14.934s (firmware) + 3.528s (loader) + 3.385s (kernel) + 3.445s (userspace) = 25.293s 
graphical.target reached after 3.178s in userspace

$ systemd-analyze blame
1.116s systemd-logind.service                                                                   
 915ms systemd-journal-flush.service                                                            
 761ms udisks2.service                                                                          
 489ms apparmor.service                                                                         
 388ms dev-sda1.device                                                                          
 301ms upower.service
On reste à 15 secondes pour le firmware. Quelles sont les pistes à explorer ?
Est-ce que les 3 secondes d'attente de grub sont inclues ?

Optimisation

#6Messageil y a 3 ans

bonjour

il faut prendre une mesure sans man-db ni fstrim car ils sont des services exceptionnels et longs

firmware 15 secondes
c'est une valeur normale en uefi (qui me parait énorme par rapport à du non uefi... ?) c'est tout ce qui est avant le chargement de grub

Tes partitions me sembles incohérentes !
/var
- sur disque dur donc lent !
- 5Go c'est vraiment petit (donc pas de snap, docker, ...)
Si tu as une partie de ton système sur disque dur , tu vas donc ralentir le chargement de ton système
Surtout que ta partition système fait 200Go : donc pas d’intérêt à avoir un /var sur autre partition ; on ne fait cela que si notre partition système est trop petite.

Si l'on désire profiter pleinement de la vitesse du ssd alors il faut avoir son home sur le ssd avec des répertoires datas qui pointent vers le disque dur (téléchargement, musique, vidéos,...) Et cela permet d'avoir moins d'espace disque jamais utilisé sur le ssd (200Go pour système !)
rappel : les ssd ne sont plus en sucre : maintenant on peut écrire plusieurs dizaines de Go dessus par jour sans l'user prématurément (voir TBW de ton ssd)

/etc/fstab
- pourquoi mettre noatime sur chaque partition ?
- la ligne /tmp ... je n'ai rien sous manjaro et sous archlinux et ai quand même un /tmp virtuel en mémoire (fait automatiquement par systemd)


apparmor
Obligatoire uniquement si on désire installer du snap (une ligne dans notre config grub pour bien dé-installer)
rappel : ces services se lancent en parallèle(presque) donc supprimer apparmor.service ne va pas te faire gagner 489ms mais peut-être 0,1 seconde voir moins :wink:

Optimisation

#7Messageil y a 3 ans

si tu utilise ni les snaps , et donc apparmor
mettre a 0 au niveau /etc/default/grub ( apparmor=0)
et retirer apparmor

pour la gestion des disques modifier :
/etc/udev/rules.d/60-scheduler.rules

# /etc/udev/rules.d/60-scheduler.rules
#
# set scheduler for non-rotating disks
# WARNING:  blk-mq scheduler REQUIRED scsi_mod.use_blk_mq=1 boot flag
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"
# set bfq-mq scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

Optimisation

#8Messageil y a 3 ans

J'avais mis /var sur disque dur car j'avais lu qu'il y avait beaucoup d'écriture, peut-être que l'information était périmée. Je n'utilise ni snap, ni docker.
Je devrais copier mon var sur le SSD ?

Pour fstab, c'est "le systeme" qui a mis noatime sur chaque partition.

Dans /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet apparmor=1 security=apparmor resume=UUID=5fddf621-af91-41b5-afdd-5816a9b41222 udev.log_priority=3"
Je supprime "apparmor=1 security=apparmor" de la ligne ? Si je mets juste apparmor=0, quid de security= ?
Et je peux supprimer le paquet ? si je supprime le paquet d'abord, il modifie le fichier grub lui même ?

Optimisation

#9Messageil y a 3 ans

la sécurité ne concerne que les paquets snap
apparmor n'est pas utile dans les autres cas

Optimisation

#10Messageil y a 3 ans

Ok, mais dans la ligne apparmor=1 security=apparmor
J'ai mis apparmor=0
mais l'autre partie security=apparmor j'en fait quoi ? je laisse comme ça ?

Edit : il faut retirer la partie security=apparmor, et ensuite lancer sudo update-grub

Optimisation

#11Messageil y a 3 ans

Bonjour,

J'ai gagné 10 secondes au démarrage.

En editant la ligne du grub, à la seconde ligne, il y a :

GRUB_TIMEOUT=10

j'ai remplacé cette valeur par 0, mise à jour du grub manuellement, et ensuite, redémarrage, et nickel.

Par contre je précise que je n'ai n'y Dual Boot, ni aucun autre O.S. sur le disque, juste Manjaro. Cette manip n'est pas à faire si vous avez un Dual Boot ou un autre O.S. installé.

Optimisation

#12Messageil y a 3 ans

je jamais mettre 0 sur ce timer par grub
le jour ou tu as un souci et que tu as besoin passer par ce grub ,
tu ne pourra pas y parvenir par le clavier

minimum 1 à 2 secondes

Optimisation

#13Messageil y a 2 ans

J'ai déplacé /var sur le disque SSD,
Maintenant j'ai un bien meilleur temps :

$ systemd-analyze
Startup finished in 15.608s (firmware) + 1.154s (loader) + 3.196s (kernel) + 1.912s (userspace) = 21.871s 
graphical.target reached after 1.019s in userspace
Merci encore pour vos conseils :merci:
Répondre