10
2009
Accélérer le boot de debian et ubuntu
Par macsim
EDIT : Après plusieurs tests cette méthode semble donner plus de satisfaction dans les machines virtuelles que sur une machine physique.
J’ai tester sur Virtualbox et Xen.
Dans le fichier /etc/init.d/rc au niveau de la ligne 32 on trouve l’option CONCURRENCY=none avec ce bloc:
Specify method used to enable concurrent init.d scripts.
Valid options are ‘none’, ‘shell’ and ‘startpar’. To enable the
concurrent boot option, the init.d script order must allow for
concurrency. This is not the case with the default boot sequence in
Debian as of 2008-01-20. Before enabling concurrency, one need to
check the sequence values of all boot scripts, and make sure only
scripts that can be started in parallel have the same sequence
number, and that a scripts dependencies have a earlier sequence
number. See the insserv package for a away to reorder the boot
automatically to allow this.
Ce qui donne grosso-modo:
Spécifier la méthode utilisée pour le mode concurrent des scripts init.d.
Les options valides sont ‘none’,'shell’ et ‘startpar’.
Pour activer l’option concurrente au boot, les scripts init.d doivent être ordonnées
pour permettre la concurrence. Ce n’est plus le cas avec les séquences de boot par défaut
dans Debian depuis le 20-01-2008.
Avant d’activer la concurrence, la valeurs des séquences de tous les scripts de boot doivent
êtres vérifiées et il faut s’assurer que seul les scripts qui peuvent être lancés en parallèle
ont le même numéro de séquence et que les dépendances des scripts ont un numéro de séquence inférieur.
Jetez un coup d’oeil au package insserv pour permettre un réordonnement automatique du boot.
L’option ‘startpar’ fait un lancement en parallel des scripts init.d avec une sortie sérialisée.
L’option ‘shell‘ semble si j’ai bien compris générer un cache de lecture “readahead”.
Après avoir essayé l’option shell je tombe vraiment sur un résultat intéressant.
Le temps comprend le démarrage d’une debian sid depuis grub jusqu’à GDM dans une machine virtuelle virtualbox.
- Avec l’option ‘none’ je mets 49,74 secondes
- Avec l’option ‘startpar’ je mets 35,12 secondes.
- Avec l’option ‘shell’ je mets 28,16 secondes.
Pour ma part voici comment j’ai reconfiguré le tout.
Pour optimiser le démarrage j’ai installé insserv que je ne connaissait pas du tout, j’ai lancer update-bootsystem-insserv pour optimiser les scripts init.d.
Ça marche plutôt pas mal.
Je n’ai pas testé sur ubuntu mais l’option est bien présente dans /etc/init.d/rc si vous avez des résultats concluant fates le moi savoir.
Related Posts
13 Commentaires + Commenter
Laisser un commentaire
Catégories
Mots-clefs
Video
Archives
- avril 2013
- décembre 2012
- septembre 2012
- juin 2012
- mai 2012
- février 2012
- janvier 2012
- septembre 2011
- août 2011
- juillet 2011
- juin 2011
- avril 2011
- mars 2011
- février 2011
- octobre 2010
- septembre 2010
- juin 2010
- mai 2010
- février 2010
- janvier 2010
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
- novembre 2008
- octobre 2008
- septembre 2008
- juillet 2008
- juin 2008
- mai 2008
- avril 2008
- mars 2008
- février 2008
- janvier 2008
- novembre 2007
- octobre 2007
- septembre 2007
- août 2007
- juillet 2007
- juin 2007
- mai 2007
- avril 2007
- mars 2007
- février 2007
- janvier 2007
- décembre 2006
- novembre 2006
- octobre 2006
- septembre 2006
J’ai essayé rapidement, sans chrono, je n’ai pas vu de différence notable sur une ubuntu 9.04 de base.
Je réinstallerai virtuabox et je ferai quelques tests plus tordus, plus sereinement que sur mon système tout propre
Pas vu de différence non plus sous ubuntu 9.04. Ceci dit, je n’ai pas touché à insserv qui semble assez dangereux si mal utilisé…
J’ai essayer sur 2 système *buntu et bootchart pour mesurer le temps de boot :
- en machine virtuel (Vbox) avec Kubuntu 9.04 : 13 sec sans, 12 sec avec.
- mon portable (T2250 1,73Ghz, 1Go, 5400tpm) : 26 sec sans, 26 sec avec.
Ce soir je test sur mon fixe (E8400 3Ghz, 6Go), mais à mon avis ça va pas changer grand chose.
Je suis un peu déçu car le billet était pas mal, j’avais espoir d’optimiser ma bécane…. sniff
J’ai suivis la procédure avec insserv.
@Toutanc, il y a la commande update-bootsystem-insserv restore en cas de pépin, ça remet le init.d/rc d’origine. Bon, c’est sur que si ça boot plus du tout, c’est foutu ^^
Peux-tu donner plus d’explications STP sur la dangerosité de insserv (je ne me suis pas documenté là dessus) ?
Merci d’avance.
Dsl pour le double post : j’ai tester uniquement avec l’option “shell”.
C’est normal que bootchart donne a une seconde près le meme temps, l’astuce n’accélère pas le boot réel, elle donne juste la main plus rapidement, c’est pour ça que mes tests étaient chronométrés entre grub et GDM, avec l’option shell on arrive plus vite à la fenetre de connection. Après le temps réel de boot évidament ça reste le meme.
Mais j’aurais du choisir un titre plus explicite c’est de ma faute.
Donc si je comprends bien, ton astuce n’est utile que si on utilise activement GDM ou KDM (pas d’auto login), c’est ça ?
Dans ce cas, en mode multi-utilisateur c’est très bien.
Et l’autre option, ça donne quoi ?
En tout cas, je suis toujours à la recherche d’astuce pour accélérer le boot des *buntu. J’ai beau lire les données de bootchart, je ne sais pas les interpréter et donc, je ne peux/sais pas mettre les mains dans le cambouis.
@VV666 :
La dangerosité tient à ce que tu soulignes toi même: il se peut que ça ne démarre plus… Bon, après, faut voir ce qui peut se réparer…
Je reste pour l’instant à 1 min 09 de temps de boot, depuis le moment ou j’appuies sur la touche ON, jusqu’à l’apparition du fond d’écran. Faut vraiment que j’optimise ça
@ Toutanc :
Si tu ne passes pas par insserv, il va falloir que tu réorganises toi-même tes /etc/rc*.d/ sans quoi tes scripts ne seront pas lancés en parallèle.
Quoi qu’il en soit, je n’ai jamais entendu quelqu’un dire qu’insserv avait cassé son système !
@vv221 :
Du coup, j’ai tenté
Je n’ai pas observé de différence
insserv s’est plaint de boucles dans mes init.d Seul le premier script était fautif (un script manuel sans LSB headers). C’est déroutant car ça sort un paquet d’erreurs.
Dans ce cas, pensez à ce qui est dit ici:
{{
aptitude install graphviz
/usr/share/insserv/check-initd-order -g > boot.dot
dotty boot.dot
}}
Salut Macsim, j’ai essayé ton astuce sur une Ubuntu virtualisée via VirtualBox, le changement n’est pas flagrant, cependant, c’est vrai qu’on “prend la main” un peu plus rapidement lorsque le bureau gnome se charge…
Par contre, ça a modifié le comportement d’un script que j’avait mis au démarrage pour monter systématiquement le dossier partagé Host/Guest.
C’est pourquoi je partage ce petit point avec ceux qui tenteront de faire cette optimisation sur leur machine virtuelle (si ils sont comme moi, c’est à dire au boulot avec un Windows XP “compliant” et une Ubuntu 9.04 qui tourne en VM histoire de garder un lien avec le libre).
Bye bye !
c’est toujours dur d’écrire sur des sujets comme ça
ya tout plein de paramètre à prendre en compte
multi-user vs mono-user; que veut dire plus rapide; les scripts utilisés / pas util
c’est sûr que la parallélisation des processus au démarrage accélère le boot.
mais enlevé l’option de booter sur cd-rom ou usbkey au bios itou.
éliminer tout les scripts pas utilisé au démarrage itou.
passé en mode mono user au lieu du multi user; (runlevel 2 ou lieu de 5)
enlevé KDM et Gnome pour mettre slim et lxde …
http://www.linux.com/archive/feed/53613
g trouvé ça
http://wiki.debian.org/BootProcessSpeedup
y parle du readahead
ainsi que kexec-tools
et d’utiliser dash au lieu de bash
# Specify method used to enable concurrent init.d scripts.
# Valid options are ‘none’ and ‘makefile’. Obsolete options
# used earlier are ‘shell’ and ‘startpar’. The obsolete options
# are aliases for ‘makefile’ since 2010-05-14. The default since
# the same date is ‘makefile’, as the init.d scripts in Debian now
# include dependency information and are ordered using this
# information. See insserv for information on dependency based
# boot sequencing.
CONCURRENCY=makefile