Improving performance (Français)/Boot process (Français)
Améliorer les performances de démarrage d'un système peut permettre de réduire les temps d'attente au démarrage et sert de moyen d'en apprendre davantage sur la façon dont certains fichiers et scripts système interagissent les uns avec les autres. Cet article tente de regrouper les méthodes permettant d'améliorer les performances de démarrage d'un système Arch Linux.
Analyser le processus de démarrage
Utilisation de systemd-analyze
systemd fournit un outil appelé systemd-analyze qui peut être utilisé pour afficher les détails temporels du processus de démarrage, y compris un graphique svg montrant les unités en attente de leurs dépendances. Vous pouvez consulter les fichiers d'unités qui ralentissent votre processus de démarrage. Vous pouvez alors optimiser votre système en conséquence.
Pour consulter le temps passé dans l'espace noyau et l'espace utilisateur lors du démarrage, il suffit d'utiliser :
$ systemd-analyze
Pour lister les fichiers d’unités démarrés, triés par le temps que chacun d'entre eux a pris pour démarrer :
$ systemd-analyze blame
À certains moments du processus de démarrage, les choses ne peuvent pas continuer tant qu'une unité donnée ne réussit pas. Pour consulter les unités qui se trouvent à ces points critiques de la chaîne de démarrage, faites :
$ systemd-analyze critical-chain
Vous pouvez également créer un fichier SVG qui décrit graphiquement votre processus de démarrage, de manière similaire à Bootchart :
$ systemd-analyze plot > plot.svg
Consultez systemd-analyze(1) pour plus de détails.
Utilisation de bootchart2
Vous pouvez également utiliser Bootchart2 pour visualiser la séquence de démarrage.
Utiliser systemd au lieu de busybox lors de l'init précoce
Par défaut, la configuration Mkinitcpio utilise les hooks base et udev pour construire les initramfs. Des temps de démarrage plus rapides peuvent être obtenus en les remplaçant par systemd.
Consultez Mkinitcpio (Français)#Hooks communs pour plus de détails. Consultez également Fsck (Français)#Vérification au démarrage si vous remplacez le hook fsck.
Compilation d'un noyau personnalisé
La compilation d'un noyau personnalisé peut réduire le temps de démarrage et l'utilisation de la mémoire. Cependant, avec la standardisation de l'architecture 64 bits et la nature modulaire du noyau Linux, ces avantages peuvent ne pas être aussi importants que prévu. Consultez Kernel (Français)#Compilation pour plus d'informations.
Initramfs
Dans une approche similaire à #Compilation d'un noyau personnalisé, l'initramfs peut être allégé. Une manière simple est d'inclure le «hook» autodetect de mkinitcpio.
Si vous voulez aller plus loin, consultez Minimal initramfs.
Selon votre matériel (processeur et vitesse de stockage), utiliser lz4 au lieu de l'option de compression par défaut zstd peut être plus rapide puisque la vitesse de décompression plus rapide lors du démarrage compense généralement la taille légèrement plus grande de l'initramfs qui doit être lu depuis le disque. Consultez Mkinitcpio (Français)#COMPRESSION.
Choisir la manière adéquate de démarrer pour les services
Une fonctionnalité centrale de systemd est l'activation par D-Bus et les sockets. Cette fonctionnalité devrait être préférée dans la plupart des cas, car elle permet aux services de n'être démarrés que lors de leur premier accès, ce qui est généralement une bonne chose (par exemple, avoir cups.service activé au démarrage n'est généralement pas utile pour une utilisation sur un ordinateur de bureau, activez plutôt cups.socket qui ne démarrera le service que lors de l'impression).
Cependant, si vous savez qu'un service (comme upower) sera toujours démarré au démarrage, alors le temps de démarrage global peut être réduit en le démarrant le plus tôt possible. Activez upower.service pour ce faire (si le fichier de service est configuré pour cela, ce qui est le cas dans la plupart des cas).
Ceci fera en sorte que systemd démarre UPower dès que possible, sans causer de concurrences avec l'activation par socket ou D-Bus.
Démarrage échelonné des disques
Certains matériels implémentent staggered spin-up, ce qui amène le système d'exploitation à sonder les interfaces ATA en série, ce qui permet de faire tourner les disques un par un et de réduire la consommation de pointe. Cela ralentit la vitesse de démarrage et, sur la plupart des matériels grand public, n'apporte aucun avantage puisque les disques démarrent déjà immédiatement à la mise sous tension. Pour vérifier si SSS est utilisé :
# dmesg | grep SSS
S'il n'a pas été utilisé pendant le démarrage, il n'y aura pas de résultat.
Pour le désactiver, ajoutez libahci.ignore_sss=1 paramètre du noyau.
Montages de systèmes de fichiers
Grâce au hook fsck de mkinitcpio, vous pouvez éviter un remontage éventuellement coûteux de la partition racine en remplaçant ro par rw sur la ligne du noyau : les options peuvent être définies avec rootflags='rw,other_mount_options. L'entrée doit être supprimée du fichier /etc/fstab, sinon le systemd-remount-fs.service continuera à essayer d'appliquer ces paramètres. On peut aussi essayer de masquer cette unité.
Si Btrfs est utilisé pour le système de fichiers racine, il n'y a pas besoin d'un fsck à chaque démarrage comme pour les autres systèmes de fichiers. Si c'est le cas, le hook fsck de mkinitcpio peut être supprimé. Vous pouvez aussi vouloir masquer le systemd-fsck-root.service, ou lui dire de ne pas vérifier le système de fichiers racine à partir de la ligne de commande du noyau en utilisant fsck.mode=skip. Sans le hook fsck de mkinitcpio, systemd vérifiera tout système de fichiers pertinent avec le systemd-fsck@.service.
Vous pouvez également supprimer les systèmes de fichiers API de /etc/fstab, car systemd les montera lui-même (consultez pacman -Ql systemd | grep '\.mount$' pour une liste). Il n'est pas rare que les utilisateurs aient une entrée /tmp reportée de sysvinit, mais vous avez peut-être remarqué dans la commande ci-dessus que systemd s'en occupe déjà. Par conséquent, elle peut être supprimée en toute sécurité.
D'autres systèmes de fichiers, comme /home ou partition système EFI, peuvent être montés avec des unités de montage personnalisées. L'ajout de noauto,x-systemd.automount aux options de montage mettra en mémoire tampon tous les accès à cette partition, et la fsckera et la montera lors du premier accès, réduisant ainsi le nombre de systèmes de fichiers qu'elle doit fscker/monter pendant le processus de démarrage.
- Ceci rendra votre système de fichiers
/homede typeautofs, ce qui est ignoré par locate par défaut. L'accélération de l'automontage de/homepeut ne pas dépasser une seconde ou deux, selon votre système, donc cette astuce peut ne pas en valoir la peine. - Si le système est installé dans un sous-volume btrfs (plus précisément, le répertoire racine
/est lui-même un sous-volume) et que/homeest un système de fichiers distinct, vous pouvez également empêcher la création d'un sous-volume/home. Masquez le fichier tmp dehome.conf:ln -s /dev/null /etc/tmpfiles.d/home.conf.
Moins de sortie au démarrage
Pour certains systèmes, particulièrement ceux avec un SSD, la lenteur des performances du TTY est en fait un goulot d'étranglement, et donc moins de sortie signifie un démarrage plus rapide. Consultez l'article Silent boot pour des suggestions.
Changer le chargeur d'amorçage
Changer votre chargeur d'amorçage (par exemple, un bootloader plus simple tel que systemd-boot) peut réduire le temps de démarrage de quelques secondes.
Si votre configuration le permet, essayez d'utiliser uniquement EFISTUB pour des temps de démarrage encore plus courts.
Suspendre en RAM
La meilleure façon de réduire le temps de démarrage est de ne pas démarrer du tout. Privilégiez plutôt la suspension de votre système en RAM.