Il existe plusieurs outils destinés à l'accélération du boot. Ils sont à utiliser dans des situations bien précises. La plupart des distributions intègre des solutions génériques destinées à apporter un gain raisonnable à un parc composé de nombreuses machines différentes. Par conséquent la solution installée par défaut n'est pas forcément LA meilleure pour votre plate-forme.

Gardez en mémoire que les optimisations présentées ici ne viennent qu'après un travail de tri dans les services qui se lancent au démarrage. Si votre machine met plus de 40 secs pour arriver au login, posez-vous quelques questions... (du genre: Comment avez-vous réussi à reproduire un comportement typique de Windows sur Linux ?).

alt_text

D'une manière générale la lecture des fichiers sur un disque est moins rapide que la lecture depuis la mémoire. De plus, il est fréquent de devoir lire les mêmes informations plusieurs fois à des intervalles de temps proches. Les systèmes d'exploitation modernes ont suffisamment de mémoire (sauf si vous êtes sur Windows puisque plus de 2Go sont occupés par le splendide A(z)ero), pour conserver en cache les données récemment manipulées. Notez que l'écriture est également prise en charge ; en effet, les fichiers les plus fréquemment écrits sont aussi les plus fréquemment lus ; différer l'écriture sur le disque est un bon moyen d'accélérer l'exécution des programmes.

La synchronisation cache-disque est réalisée régulièrement (commande 'sync' sous Linux/GNU). Ceci explique d'ailleurs pourquoi il est déconseillé d'éteindre un système "à la prise", puisqu'une perte de données est alors possible (théoriquement cela vaut aussi pour la déconnexion des périphériques de stockage externe).

Lorsqu'une demande importante de mémoire est faite, le système fait appel à des algorithmes pour vider le cache (qui se remplit progressivement jusqu'à occuper tout la RAM libre).

Toujours pas convaincu ? Démonstration lors d'une recherche de fichiers sur un disque dur de 400Go plein (de films culturels):

État de la mémoire avant la recherche:

alt_text

État de la mémoire après les recherches, résultat de la première recherche puis résultat de la seconde recherche (le fichier a été ajouté entre temps).

alt_text

Conclusion: La structure des répertoires est également mise en cache/indexée.

Maintenant testons une recherche sur le contenu des fichiers et non plus leurs noms. J'utilise ici un alias très utile, placé dans mon ~/.bashrc, pour rechercher des mots dans les fichiers et dossiers d'un répertoire de manière récursive:

function search() { echo "Recherche de $1 ..."; grep -in -R "$1" ./*; }

La taille du cache augmente très rapidement jusqu'à saturer la mémoire.

alt_text

À ce moment-là pour profiter du cache, plusieurs solutions s'offrent à moi:

  • Disposer de 400Go de RAM,
  • N'avoir que ~5Go de données sur la partition,
  • Avoir un SSD pour pallier la chute de débit en lecture.

Ces expériences montrent que la structure des répertoires, et les fichiers manipulés, sont mis en cache pour accélérer les opérations futures. Pour revenir au sujet d'origine, tous les programmes proposant l'accélération du boot sont au moins basés sur un pré-chargement forcé du cache avec les fichiers d'intérêt.

Voici un tableau récapitulatif présentant les différents programmes que j'ai répertoriés.

ProgrammeFonctionnementConditionFacilité d'utilisation
ReadaheadBootsystemd v < 216+
uReadaheadBootUbuntu++
Readahead-fedoraBoot!= Ubuntu-
PreloadUserspace post-login; == Prefetch Windows++
e4ratBoot + Userspace post-loginHDD + ext4-


La réelle optimisation que je propose dans ce tuto est avec e4rat, mais je ne peux la présenter en passant sous silence les autres solutions.

Sommaire

uReadahead

Ce programme ouvre les fichiers avant leur utilisation. Le boot est accéléré puisque les fichiers utilisés sont alors déjà en mémoire.

La liste des fichiers d'intérêt (collecte des données) est réinitialisée automatiquement après l'installation, ou 1 fois par mois, ou à chaque modification/installation des scripts de démarrage.

Le programme requiert un patch noyau, inclus sur Ubuntu.

L'automatisation est son gros point fort, c'est la raison pour laquelle ce programme est présent sur Ubuntu. Néanmoins alors qu'il offre une amélioration des performances avec un SSD, ses performances sont moyennes sur un disque classique formaté en ext4 pour lequel on préfèrera largement e4rat.

Lire: Launchpad Ubuntu über-Readahead

Readahead

Autrefois implémenté dans Systemd, il a été retiré depuis la version 216 (non comprise):

This feature's future is questionable due to a lack of attention. The majority of the developers make use of SSDs and thus don't use the feature. [...] I fully understand that not everybody uses SSDs yet, and also that theoretically doign systemd-readahead on SSD could be beneficial still (since RAM is still orders of magnitude faster than SSDs), but it's really not about that, it's about maintainership and giving the tool the love it needs.Source: mail-archive systemd-devel

Les systèmes d'exploitation manquent de développeurs. Dont acte.

Connaître sa version de systemd (sous Debian Jessie vous aurez la version 215 et sous Ubuntu 15.x la version 219):

systemd --version

Si vous n'êtes pas sur Ubuntu, et que vous souhaitez tout de même tester Readahead, lisez la suite expliquant son fonctionnement, puis allez vers la section readahead-fedora plus bas.

Readahead vient avec deux services:

  • systemd-readahead-collect: Collecte les fichiers utilisés durant le démarrage.
  • systemd-readahead-replay: Lit et charge les fichiers dans le cache durant le démarrage.

Sur les disques mécaniques, le service replay organisera les requêtes de lecture selon la localisation des fichiers sur le disque. Sur les disques SSD, l'organisation se fera selon la date originelle d'accès. Si le système de fichiers l'autorise, le service collect défragmentera et réorganisera les fichiers.

Activation avec systemd:

systemctl enable systemd-readahead-collect systemd-readahead-replay

PS: Plusieurs redémarrages sont nécessaires pour affiner la collecte (apprentissage).

Lire: Man-pages - Readahead + systemd, Improve boot on Debian - Readahead

Readahead-fedora

Implémentation de readahead (voir ci-dessus) indépendante de systemd, utilisable sur Debian, Fedora et probablement d'autres...

Paquet à installer:

sudo apt-get install readahead-fedora

Description du paquet:

  • Organisation du chargement des fichiers selon la localisation sur le disque,
  • Pré-chargement de la structure des répertoires si système de fichiers ext,
  • Ouverture des fichiers sans modification de la date d'accès,
  • Démon de collecte.

L'activation de la collecte des données est manuelle et se fait via la création d'un fichier dans la racine (donc pas d'apprentissage sur les données à charger):

sudo touch /.readahead_collect

Lire: Improve boot on Debian - Readahead

Preload

Il s'agit de l'équivalent de prefetch sous Windows.

Preload permet d'utiliser une partie de la mémoire vive de votre ordinateur afin de pré-charger les applications que vous utilisez le plus souvent. Pour y arriver il analyse vos habitudes afin de cibler ces applications et vous faire gagner ainsi de précieuses secondes au lancement de ces applications. Nb : preload n'accélère pas la procédure de démarrage d'Ubuntu.Source : Documentation Ubuntu.

Voici un tuto complet, avec des tests, et sa conclusion:

So, as a final word, if you have a reasonably lager RAM & use Ubuntu, and looking for a way to speed up the application loading times, without sacrificing much, then yes, ‘preload’ is worth trying. If you have different opinions, you’re more than welcome to throw in a comment.

e4rat

e4rat a pour but d'éliminer les délais inhérents à la rotation des disques durs mécaniques d'une part, et à la recherche des fichiers à leur surface d'autre part. Il n'y a (presque) pas de fragmentation des fichiers sur les systèmes de fichiers ext4, par conséquent, un fichier est stocké sur des secteurs contigus du disque dur ; toutefois, parce que les centaines de fichiers lus lors du boot sont éparpillés sur le disque, leur accès reste couteux.

La première optimisation requiert le déplacement des fichiers concernés en début de disque, les uns à côté des autres. Elle permet ainsi d'accroître de manière impressionnante le débit en lecture (différence principale entre e4rat et readahead).

La deuxième optimisation consiste à pré-charger tous les fichiers en RAM (mise en cache) au cours de la phase précoce du boot. Les services et logiciels n'auront qu'à interroger la RAM en lieu et place du disque dur, évitant au passage des délais d'attente et la gestion de priorités.

Comme les disques SSD n'ont ni plateaux en rotation, ni têtes de lecture, les délais d'accès sont inexistants ; les optimisations faites par e4rat sur le système de fichiers n'auront donc aucun effet notable. Les utilisateurs de SSD préfèreront utiliser uReadahead (voir section plus haut).

Voici quelques liens complémentaires: Tuto complet avec captures d'écran, Autre tuto, Doc, Sources.

Installation

L'installation est un peu fastidieuse mais largement faisable. Suivez le guide ! PS: Tout ceci est pour les distributions de type Debian. Pour le reste vous allez sûrement devoir compiler les sources ou utiliser d'autres outils pour gérer les paquets. Bref, vous l'aurez compris: je me moque des autres distris :p

e4rat rentre en compétition avec uReadahead installé par défaut sur Ubuntu. Il faut donc le désinstaller:

apt-get purge ureadahead ubuntu-minimal

Allez sur le site du projet (le paquet n'est pas dans les dépôts):

http://sourceforge.net/projects/e4rat/files/

Téléchargez la dernière version:

e4rat_0.2.3_amd64.deb

Vous pourriez installer ce paquet avec la commande suivante:

sudo dpkg -i e4rat_0.2.3_amd64.deb

Sauf que l'outil dpkg ne gère pas les dépendances tierces (ici les paquets libblkid1 et e2fslibs). Je déconseille fortement l'utilisation de cette commande quand on ne sait pas ce que l'on fait. Il existe un logiciel qui gère les dépendances pour vous, à la manière de apt-get: gdebi.

sudo apt-get install gdebi
gdebi-gtk # Démarre l'interface graphique

Faites 'Fichier/Ouvrir' puis cherchez votre .deb. Installez-le, la suite est intuitive.

Configuration

Activez la collecte des données en modifiant les paramètres passés au noyau. N'ayez pas peur, il suffit d'éditer le fichier '/etc/default/grub', repérez ensuite la ligne 'GRUB_CMDLINE_LINUX_DEFAULT' et ajoutez-y:

GRUB_CMDLINE_LINUX_DEFAULT="COMMANDES_PREEXISTANTES init=/sbin/e4rat-collect"

Régénérez ensuite la configuration de grub:

update-grub

Au prochain démarrage, e4rat-collect va enregistrer les données dans le fichier '/var/lib/e4rat/startup.log'.

Notez que la collecte se poursuit par défaut jusqu'à 2 minutes après le login. Vous pouvez donc lancer vos logiciels préférés, ils seront optimisés aussi. Notez aussi que si vous lancez des applications comme Firefox, vous allez provoquer la mise en cache des données du cache du navigateur... Ces données étant temporaires par définition, cherchez l'erreur... Faire cela est contre-productif ! e4rat n'est pas vraiment conçu pour le pré-chargement des programmes de l'utilisateur (utilisez 'preload' pour ça); ici il sert surtout à optimiser le chargement du bureau KDE.

Après la collecte (2 min), passez en runlevel 1 (ou redémarrez en mode rescue/recovery):

sudo init 1

ou

sudo systemctl isolate rescue

Puis exécutez cette commande jusqu'à ce qu'il n'y ait plus rien à optimiser (il s'agit du déplacement des fichiers sur le disque):

e4rat-realloc /var/lib/e4rat/startup.log

Restez dans la console et éditez à nouveau '/etc/default/grub' pour remplacer '4rat-collect' par '4rat-preload':

sudo nano /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="COMMANDES_PREEXISTANTES init=/sbin/e4rat-preload"

(Ctrl + O pour quitter; Vous pouvez aussi utiliser Vim...)

Régénérez ensuite la configuration de grub:

update-grub

PS: Le fichier de configuration est '/etc/e4rat.conf', vous pouvez y modifier la durée de collecte (2 min par def) et le niveau de verbosité (verbose 1). Vous aurez également noté qu'il n'y a pas d'apprentissage sur les données à charger avec cette solution. Il faudra refaire une collecte manuelle si votre système change.

Résultats

J'utilise dans cette partie les graphiques générés par systemd-analyse et par bootchart2. Voir le tuto Mesurer les performances du démarrage de sa machine.

Avant, d'après systemd:

alt_text

Après, d'après systemd:

alt_text

Sans e4rat, le système attend l'exécution de services bloquants (malgré le fait qu'ils soient lancés en parallèle) ; le tout durant 24 à 28 secondes. Avec e4rat, les services mettent 2,5 secondes à s'exécuter. Le pré-chargement dure ~11 secondes (dont 3 secondes incompressibles pour le chargement du noyau). Le système se lance donc en ~17 secondes.

Bootchart nous donne plus d'infos sur l'utilisation du disque dur et sur la période après login.

alt_text

Nous avons un pic de débit en lecture (courbe verte) à 385Mo/sec (peut encore être amélioré car on remarque que le disque est encore utilisé par la suite). Ce pic est suivi d'une période de calcul assurée par le CPU. Les attentes liées aux I/O sont alors limitées (courbe bleue du graph, représentant l'utilisation optimale du CPU).

Le système est pleinement utilisable ~40 secondes après la mise sous tension (en comptant le temps nécessaire pour entrer le login vers 20 secondes).

Les autres graphiques (Cumulative CPU usage by process, et Cumulative I/O usage by process) servent à cibler les processus trop gourmands. Le ménage a déjà été fait ici mais il reste probablement encore du travail pour optimiser la détection du matériel par udev, ainsi que le chargement du serveur X (X.org).

Conclusion et discussion au sujet de l'utilité des SSD

Avec e4rat vous voyez précisément:

  • Les services vraiment couteux en temps CPU,
  • Un aperçu du comportement de votre système si il était installé sur un SSD.

En effet, les 11-3 = 8 secondes de pré-chargement au démarrage sont les seules secondes qu'un SSD sera capable de réduire. Vous l'avez vu, le pic de lecture est à 385Mo/sec. Un SSD moyen a un débit constant de 400-500Mo/sec. On peut donc tabler sur une étape de boot de ~10 secondes. Le chargement du bureau lui aussi sera influencé. De combien ? Difficile à dire. Tablons sur un délai après mise sous tension de ~30 sec.

Cela vaut-il le coup d'utiliser un SSD pour gagner 10 secondes au démarrage ? J'insiste sur la notion de démarrage (la chose que l'on fait 1 fois par jour voire moins), puisqu'il faut la distinguer de la notion de mise en veille prolongée trouvée sur Mac et Windows. Sur Linux/GNU ça s'appelle l'hibernation et mon système met alors 20 secondes à redémarrer. Notez que durant l'hibernation, le cache disque est effacé. Un utilisateur de SSD aura l'impression (justifiée), que sa machine est plus rapide que sur un HDD pendant cette brève phase de reconstruction du cache.

Pour le reste (c.-à-d. le comportement général de la machine), les gens qui ont un SSD jugent leur système "plus réactif" au premier lancement des applications. En fait ils sont dupés par la mise en cache préalable de leurs applications. Appelez ça prefetch/preload, respectivement pour Windows et Apple/Linux/GNU.

Le pré-chargement est évidemment plus rapide sur un SSD mais est-il utile ? Personnellement je n'utilise pas preload. Je trouve inutile de surcharger le système avec des données qu'il aura jugé potentiellement utiles. De plus, si second lancement il y a, l'application sera déjà dans le cache mémoire, indépendamment du support de stockage utilisé.

Pour conclure, les SSD n'apportent que des gains minimes et/ou dispensables lorsque le système est installé dessus. Coté autonomie, ils ne valent guère mieux que les HDD ; plus les SSD sont gros, plus le nombre de puces est important, et plus la consommation électrique augmente. Bref, un SSD oui, mais seulement pour installer les jeux et ainsi accélérer le chargement des textures. Si vous êtes dans un autre cas de figure, prenez garde, votre branche phylogénétique se rapproche étrangement de cet animal:

alt_textCC BY-SA 3.0

Références