Accélérer le démarrage d'une machine Debian GNU/Linux🔗

Le boot, c'est parfois long. Souvent, on a pas que ça à faire ! C'est très vrai pour les ordinateurs portables ou les stations de travail. Mais d'une manière générale, y compris pour des grosses machines de production, j'aime bien les séquences de boot rapide. En effet, plus le boot est rapide et plus la remise en fonctionnement des services associés à la machine est rapide. Plus on gagne de secondes sur ce sujet et mieux c'est. De plus, avoir une séquence de boot rapide implique que vous ayez passé un peu de temps sur cette dernière. C'est généralement une bonne pratique d'administration système. Si vous n'avez installé que le strict nécessaire, votre séquence de démarrage sera souvent assez rapide.

Néanmoins, il existe des outils techniques qui permettent de gagner de précieuses secondes. Le premier qui me vient à l'esprit est systemd qui permet d'accélérer la séquence de démarrage en parallélisant au maximum le lancement des services, y compris si le réseau n'est pas encore configuré. Sur mes stations de travail, systemd permet d'économiser entre 5 et 10 secondes.

L'autre possibilité est d'utiliser un disque SSD pour le système. C'est le cas d'une de mes stations de travail. Néanmoins pour tout un tas d'autres machines, ce n'est pas forcément possible. Par exemple, un serveur de récupération (c'est du green-IT) n'a pas besoin d'un disque SSD. Ou peut-être n'avez-vous tout simplement pas les moyens de vous offrir un SSD.

Pour les systèmes à disques durs classiques, on peut quand même gagner du temps en utilisant un optimiseur de système de fichiers. Il existe par exemple readahead qui fonctionne avec systemd. Sous GNU/Linux Debian Wheezy, il existe un paquet nommé readahead-fedora. Le principe de ce dernier est de lire des fichiers pour les placer en mémoire. readahead est prévu pour être lancé au démarrage de la machine: il utilise une liste de fichiers à lire en amont dans un ordre bien déterminé de manière à accélérer le temps de démarrage. En effet, si on concentre les opérations de lecture de fichiers dont on aura besoin dans tout le processus de démarrage, les accès disques seront beaucoup mieux optimisés.

Mais on peut encore aller plus loin. En effet, on peut agir au sein du système de fichiers. Si tous les fichiers à lire pour accélérer la séquence de démarrage sont placés au même endroit, les uns à la suite des autres, leur lecture pour les placer en mémoire sera beaucoup plus rapide, les têtes de lecture n'ayant pas à se déplacer de manière répartie. Il y a un paquet pour ça: e4rat. Voyons comment l'installer…

e4rat est un petit logiciel qui se charge de regrouper les fichiers préchargés du système dans un endroit donné, de manière linéaire. Il ne fonctionne que sur les systèmes ext4 mais, comme btrfs n'est pas encore implémenté en standard dans toutes les distributions (et qu'il n'est pas encore prêt pour la production), nous pouvons allègrement l'utiliser.

Son principe d'utilisation est finalement assez proche de celui de readahead à la différence qu'il n'est pas vraiment géré à la sauce Debian. Certes il existe un paquet Debian sur le site web de l'utilitaire, mais il n'est pas intégré à la distribution.

e4rat utilise 3 binaires différents:

• e4rat-collect qui est un peu le readahead-collector: il fabrique une liste de fichiers ouverts de manière chronologique.
• e4rat-realloc qui s'occupe de réallouer les fichiers au bon endroit.
• enfin, on trouve e4rat-preload qui joue le rôle de readahead: ce binaire va charger les fichiers dans l'ordre requis.

Cette fois, apt-get ou aptitude ne peuvent pas nous aider. Il faut aller sur le site web du projet et télécharger le paquet debian qui va bien. Si vous utilisez autre chose que du x86 ou de l'amd64 (de l'armhf ou du mips), il faudra recompiler à la main !

# dpkg -i e4rat_0.2.3_amd64.deb

Le paquet installe quelques binaires dans /sbin/ ainsi que les pages de manuel relatives.

Pour la partie configuration, elle sort vraiment du lot Debian: il faut intervenir en amont du système et indiquer au noyau linux le nouveau nom du processus init. C'est une technique identique à celle de bootchart. Nous devrons donc gérer tout ça dans la configuration de GRUB2.

Pour résumer, voici ce que nous allons faire:

• booter le système en ayant pris soin de mettre en processus init le binaire /sbin/e4rat-collect.
• après quelques vérifications, rebooter le système en mode autonome (single) pour effectuer le repositionnement des fichiers concernés.
• enfin, il faudra indiquer dans la configuration de GRUB2 qu'on souhaite définitivement utiliser le binaire e4rat-preload en processus init pour tout le temps pré-charger les fichiers concernés.

Voici le déroulé de ces étapes.

• Ajoutez les lignes suivantes dans le fichier /etc/grub.d/40_custom (à adapter en fonction de votre noyau):

menuentry 'E4Rat collect Debian GNU/Linux,3.2.0-4-amd64' --class debian --class gnu-linux --class gnu --class os {
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set=root 9beb0590-6505-41af-8daa-cdf23a108473
	echo    'Chargement de Linux 3.2.0-4-amd64 avec E4RAT collection…'
	linux   /boot/vmlinuz-3.2.0-4-amd64 root=UUID=9beb0590-6505-41af-8daa-cdf23a108473 ro quiet init=/sbin/e4rat-collect
	echo    'Chargement du disque mémoire initial …'
	initrd  /boot/initrd.img-3.2.0-4-amd64
}

• Lancer la commande '''update-grub2''' pour mettre à jour le menu GRUB. Lancer alors un reboot de la machine et prendre soin de choisir cette nouvelle entrée.
• Le système va se lancer et créer une liste de fichiers à précharger en fonction de ce qui est lancé au niveau du système de fichiers. La liste des fichiers est stockée, par défaut, dans le fichier /var/lib/e4rat/startup.log.
• N'hésitez pas à fouiller cette liste et à virer les fichiers qui ne sont pas importants. Pour ma part, j'ai supprimé toutes les entrées qui mobilisent des fichiers de thumbnails par exemple.
• Une fois la vérification de ce fichier réalisée, il suffit de redémarrer le système en mode de dépannage (single). Lorsque le système vous donne la main (après avoir donné le mot de passe root), il suffit d'entrer la commande e4rat-realloc /var/lib/e4rat/startup.log.
• Les fichiers concernés par la réallocation vont être alors déplacés de manière à minimiser leur temps d'accès. Une fois que e4rat-realloc a terminé son travail, il suffit de rebooter sur une instance normale du système (la première entrée dans le menu de GRUB2).
• Enfin, contrairement à readahead, le pré-chargement des fichiers de e4rat est réalisé au niveau du processus init (readahead se base sur un script sysvinit). Il faut donc l'indiquer dans la configuration de GRUB2. Une méthode (un peu bourrin il faut bien le reconnaître), consiste à modifier le contenu d'une variable du fichier /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet init=/sbin/e4rat-preload"

• Après un update-grub2, à chaque reboot, le système va chargerles fichiers et tout devrait automagiquement aller plus vite.

Bien entendu cette configuration fonctionne très bien avec systemd, car elle est indépendante du système d'init de la distribution.

L'installation d'e4rat est un peu complexe. Sa configuration n'est pas vraiment dynamique: si vous installez de nouveaux paquets ou de nouvelles versions de paquets existants, il faudra recommencer l'étape de collecte des fichiers en bootant sur l'entrée GRUB E4Rat collect et relancer e4rat-realloc. Néanmoins sur un système en production où ces changements sont peu nombreux, c'est très adapté. Avec e4rat on peut gagner près de 5 à 10 secondes supplémentaires sur la séquence de démarrage. Donc, le jeu en vaut clairement la chandelle vu le faible temps d'administration système nécessaire pour mettre en place la configuration (moins de 30 minutes).

Bien entendu, e4rat n'a pas vraiment d'intérêt sur des disques SSD qui n'ont pas les mêmes problèmes de latence que les disques durs classiques. C'est la même chose pour les machines virtuelles !

Pour ma part, je l'ai déployé sur des stations de travail et des ordinateurs portables avec beaucoup de succès. Je le recommande y compris pour les serveurs de production (physiques bien sûr) comme processus à la mise en production: sur un parc un peu fourni, on peut remettre en service avec un peu d'avance et minimiser les temps d'indisponibilité. Vos utilisateurs seront plus rapidement contents et vos administrateurs systèmes nerveux un peu moins longtemps lors des redémarrages.