Archlinux.fr [Forums]

Bonjour.

Je parcours les forums depuis quelques jours, suite à mon passage de arch 32 bits à arch 64 bits. Je trouvais mon boot plus lent avec la 64 bits, alors j'ai fait quelques recherches sur le temps de boot normal des autres utilisateurs. En général, cela tourne autour de 20 secondes, moins des fois quand c'est optimisé.

Je voudrais votre avis quant à ce qui démarre chez moi, peut être pourriez vous me conseiller d'enlever 2-3 trucs inutiles.

Je vous mets le graphique généré par bootchart:

Voir le Fichier : bootchart.png

Bien à vous.

Salut,

ton système mets 35s pour booter, ce n'est pas excessif, surtout que dans ton exemple il y a 7 secondes passées à faire du fsck et 7 aussi pour dhcp. Une fois cela enlevé il ne reste plus que 20s (ok 21s exactement) cela reste très correct.

Un '@network' devrait accélérer les choses (à priori, tu n'as pas de services dépendant du réseau qui démarre)

J'ai mis @network dans mon rc.conf, je verrai au prochain reboot.

Je ne sais pas si je vais dire une grosse bêtise, mais sur la page du wiki anglophone, ils ne précisent pas si c'est dangereux de ne pas lancer fsck à chaque démarrage. Je sais que si les développeurs activent cette option par défaut dans le rc.conf, ça ne doit pas être pour faire joli, mais est ce que l'on peut tout de même s'en passer et, disons, lancer fsck régulièrement à la main?

Quel option dans le rc.conf ? Par défaut j'ai un fsck environ tous les 20 mount (donc tous les 20 démarrages).
En aucun cas il est nécessaire d'avoir un fsck à chaque démarrage

Non je dis de la merde en fait, j'ai confondu fsck avec autre chose. Mais comme l'a dit oktoberfest, je passe 7 secondes à faire du fsck. Et il ne me semble pas que mes partitions aient été checkées quand j'ai booté avec bootchart. Si?

Tu es le seul à le savoir, le plus simple est de refaire un bootchart et de faire attention

Ce que tu peux faire (à voir si tu privilégies la vitesse de boot) c'est de désactiver le fsck pour certaines partitions. Via le sixième champ du fichier /etc/fstab, tu peux (en mettant la valeur à 0) indiquer à fsck de ne pas vérifier une partition.
Tu peux aussi modifier le nombre de montages entre deux vérifications avec tune2fs.

Mais bon, perdre 7 secondes tous les 30 redémarrages, il y a pire dans la vie non ?

Ah bin si en fait, bien joué. J'ai vraiment pas eu de chance que ça se fasse à ce moment là.

Je vous mets le nouveau graphique, avec @network: (20 sec)

Voir le Fichier : bootchart.png

Donc si je comprends bien le graph, tous les programmes qui sont sous forme de barres ininterrompues sont des daemons "perpétuels". Donc on ne peut gagner en temps que sur les programmes en bandes interrompues. Est ce que je me trompe?

Au passage, je vois des petites bandes VBox[...], est ce que ça a un rapport avec virtualBox?

EDIT: Non il n'y a pas pire, c'est tellement important pour moi mon temps de boot...

Tout ce que je vois qui pourrait être bizarre, c'est modprobe qui utilise beaucoup le cpu.
L'autre ralentissement c'est X, donc reste en mode console

Effectivement VBox c'est pour VirtualBox

Ok. Que faire contre l'utilisation intempestive de modprobe? Il charge les modules celui-la, si je ne m'abuse.

Et pourquoi VirtualBox fait des trucs au démarrage? Je ne m'en sers qu’occasionnellement.

Parce qu'il charge des modules pour que tu ais le réseau dans tes vms et que tu profites de l'accélération matérielle (intel-vt), la 3D, l'usb ...

Hum...Est ce que cela vaudrait la peine de les enlever, vu le peu de temps que cela prend?

Par contre, quant au processus du bas, à quoi correspondent ils? (kthreadd, kworker, ...) Ça ressemble à des programmes de kde, avec le "k" en préfixe...

djipey a écrit :(kthreadd, kworker, ...) Ça ressemble à des programmes de kde, avec le "k" en préfixe...

Absolument pas, ce sont des processus du kernel.
Pour plus de détails:
http://askubuntu.com/questions/33640/kw ... o-much-cpu
&
http://www.linuxquestions.org/questions ... ok-883837/
nous amènent à installer et à éplucher linux-docs ... plus particulièrement /usr/src/linux-3.0-ARCH/Documentation/workqueue.txt à ce qu'il semble.

... ou alors il nous faut un maître ès-noyau linux dans le coin (qui se mette à un niveau compréhensible si possible ).

Tout ça pour dire que supprimer ce processus ne paraît franchement pas une bonne idée...

djipey a écrit :Hum...Est ce que cela vaudrait la peine de les enlever, vu le peu de temps que cela prend?

La réponse est comprise dans la question.