Improving performance (Français)/Boot process (Français) - ArchWiki

Jump to content

# Improving performance (Français)/Boot process (Français)

From ArchWiki
< Improving performance (Français)
État de la traduction: Cet article est la version francophone de Improving performance/Boot process. Date de la dernière traduction: 2022-01-26. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

Related articles

- Improving performance (Français)
- Silent boot
- Daemons (Français)
- e4rat
- Kexec

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

Astuce: Si vous démarrez via UEFI et utilisez un chargeur d'amorçage qui implémente l'interface de chargeur d'amorçage de systemd Boot Loader Interface (ce que font actuellement systemd-boot et GRUB), systemd-analyze peut également vous montrer le temps passé dans le firmware EFI et le chargeur d'amorçage lui-même.

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 une version de Bootchart pour visualiser la séquence de démarrage. Puisque vous n'êtes pas en mesure de mettre un second init dans la ligne de commande du noyau, vous ne pourrez pas utiliser l'une des configurations standard de Bootchart. Cependant, le paquet bootchart2AUR de AUR est fourni avec un service systemd non documenté. Après avoir installé bootchart2, activez `bootchart2.service`.

Vous pouvez visualiser les résultats en ouvrant `/var/log/bootchart.png`, ou si vous souhaitez plus de fonctionnalités en lançant :

    $ pybootchartgui -i

Lisez la documentation de bootchart2 pour plus de détails sur l'utilisation de cette version de Bootchart.

## 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.

Note:

- Ceci rendra votre système de fichiers `/home` de type `autofs`, ce qui est ignoré par mlocate par défaut. L'accélération de l'automontage de `/home` peut 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 `/home` est un système de fichiers distinct, vous pouvez également empêcher la création d'un sous-volume `/home`. Masquez le fichier tmp de `home.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

Si votre configuration le permet, essayez de changer votre chargeur d'amorçage ou même de ne pas en utiliser avec EFISTUB (Français).

## 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.

Category:

- Boot process (Français)