Journal Accélération de firefox sur support lent

Posté par octane le 07 avril 2009 à 11:37.

Étiquettes :

avr.

2009

Bonjour, Nal,

J'utilise une distrib linux sur clé USB, ce qui est fort pratique.
Toutefois, j'ai quelquefois des lenteurs, différentes selon les produits.

Firefox fait office de champion. Extrêmement long au démarrage, fréquents blocages lors du surf, lentissimes lors de l'utilisation de l'awesome bar, en un mot inutilisable.

Je me suis rendu compte que toutes ces lenteurs étaient dûes au support (USB + encryption). J'ai eu l'idée donc de mettre tout .mozilla/firefox en tmpfs afin d'accélérer les choses.
Et ça marche, c'est même très rapide. Problème, tout l'historique, la config, etc est perdu au redémarrage.

J'ai donc écrit un script ffirefox (pour fast firefox) qui prend le contenu de
.mozilla/firefox, le sauvegarde, monte un tmpfs sous .mozilla/firefox, réinjecte le contenu et lance firefox. L'opération inverse est faite à l'arrêt.
J'en profite pour supprimer le cache et optimiser les bases .sqlite de mon profil.

firefox est redevenu utilisable (et il est très rapide).

Je soumet le script à votre sagacité, amis lecteurs, afin que vous puissiez me dire si j'ai raté quelquechose, si vous avez d'autres idées d'optimisations, ou si ça vous plaît:



#! /bin/bash



#script fast firefox. L'idée est de mettre en RAM ~/.mozilla/firefox

# 1. on sauvegarde tout sauf le Cache

# 2. on monte le répertoire firefox en tmpfs

# Pour cela, fstab doit contenir une ligne

# tmpfs /home/octane/.mozilla/firefox  tmpfs noauto,uid=octane,user,mode=700  0 0

# 3. on detarre le contenu qui se trouve donc en RAM

# on optimise les bases sqlite3

# A la déco, on recommence, en sens inverse.

# j'ajoute des xmessage afin d'expliquer ce que fait le script



launch_ffirefox () {

xmessage -center "Launching fast firefox.. Please Wait" &

#checking if my little hack is not allready in use

if ! mount | grep "/home/octane/.mozilla/firefox" > /dev/null

then

 #Good thing

 echo "tmpfs is not mounted"

 #checking if firefox is not in use

 if ps ax | grep firefox-bin | grep -v grep > /dev/null

   then

    #do nothing

    echo "do nothing"

   else

    #ok, time to go on

    cd /home/octane/.mozilla

    rm -f firefox/Cache/*

    [ -f ff.tgz ] && rm ff.tgz

    tar cvfz ff.tgz firefox/

    mount /home/octane/.mozilla/firefox

    tar xvfz ff.tgz

    for f in ~/.mozilla/firefox/*/*.sqlite; do sqlite3 $f 'VACUUM;'; done

    killall xmessage

    /usr/bin/firefox $@

 fi

else

 #do nothing

 echo "tmpfs is mounted"

fi

}



cancel_ffirefox () {

xmessage -center "Stopping firefox, please Wait.." &

#We should have been launched by this script.

cd /home/octane/.mozilla/

rm -f firefox/Cache/*

[ -f ff.tgz ] && rm ff.tgz

tar cvfz ff.tgz firefox/

umount /home/octane/.mozilla/firefox

tar xvfz ff.tgz

killall xmessage

}



#Now we can launch this script

launch_ffirefox

cancel_ffirefox

# sqlite

Posté par Nicolas Boulay (site web personnel) le 07 avril 2009 à 11:43. Évalué à 5.

Firefox sauve régulièrement son historique pour qu'il le retrouver en cas de crache dans une base SQLlite. Or cette base fait souvent des opération sync() qui sont une tuerie d'un point de vue performance IO. Il me semble que Firefox 3.5 change ce comportement.

Je crois qu'il existe aussi une clef de configuration pour changer cette manière de faire au détriment de la sécurité des données.
"La première sécurité est la liberté"
- [^] # Re: sqlite
  
  Posté par Nicolas Boulay (site web personnel) le 07 avril 2009 à 11:46. Évalué à 4.
  
  Pour plus d'infos :
  http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
  "La première sécurité est la liberté"
- [^] # Re: sqlite
  
  Posté par octane le 07 avril 2009 à 11:52. Évalué à 5.
  
  Or cette base fait souvent des opération sync() qui sont une tuerie d'un point de vue performance IO.
  
  Maintenant que tout est en RAM, les performances sont très acceptables.
  
  Je crois qu'il existe aussi une clef de configuration pour changer cette manière de faire au détriment de la sécurité des données.
  
  En fait, en cas de crash, avec ma méthode, on retombe sur un état sain (puisque les fichiers originaux sont toujours en place).
  Je risque juste de perdre mon dernier historique.
  
  Mais ça se tente, si quelqu'un connait cette clé (ou d'autres) permettant d'accélérer les perfs, je prends
  - [^] # Re: sqlite
    
    Posté par Tabalji le 07 avril 2009 à 14:32. Évalué à 3.
    
    Mais ça se tente, si quelqu'un connait cette clé (ou d'autres) permettant d'accélérer les perfs, je prends
    
    about:config -> toolkit.storage.synchronous -> 0
    
    À utiliser à vos risques et périls. Pour plus d'infos au sujet de cette clé et du bogue en question :
    
    http://www.dslreports.com/forum/r20655561-Firefox-30-uses-fs(...)
    https://bugzilla.mozilla.org/show_bug.cgi?id=421482
    
    Pour les performances et plus encore, un bon guide (en) ici :
    
    http://www.tweakguides.com/Firefox_1.html
# Le mode verbose

Posté par franck villaume (site web personnel) le 07 avril 2009 à 11:45. Évalué à 9.

est-il vraiment nécessaire d'utiliser le mode verbose pour les tar ?

tar cvfz
tar xvfz

Le mode verbose fait des entrées-sorties inutiles. C'est pratique pour du debug mais pas plus.
- [^] # Re: Le mode verbose
  
  Posté par Snarky le 07 avril 2009 à 11:53. Évalué à 5.
  
  Je confirme que sur des archives contenant beaucoup de petits fichier, ça peut multiplier le temps de décompression par 2 ou 3... C'est du vécu.
  - [^] # Re: Le mode verbose
    
    Posté par octane le 07 avril 2009 à 12:01. Évalué à 4.
    
    J'ai énormément grossi mon script pour linuxfr afin qu'il soit le plus lisible possible.
    (comme par exemple les echo "je ne fais rien")
    
    Mais oui, ça fait perdre du temps. Curieusement, le plus gros ralentissement chez moi lors de l'utilisation d'un tar zxvf est dû au xterm.
    100% CPU pour le xterm. Si je réduis le xterm, ça detarre bien plus vite.
    - [^] # Re: Le mode verbose
      
      Posté par ZeroHeure le 07 avril 2009 à 12:12. Évalué à 7.
      
      ben c'est normal non? il faut bien gérer l'affichage de toutes ces charmantes petites lignes qui défilent.
      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Quelle distrib ?

Posté par palm123 (site web personnel) le 07 avril 2009 à 12:18. Évalué à 2.

J'utilise Toutou Linux sur clé Usb (sans chiffrer) et c'est tout à fait bon.

Et mon PC n'est pas une bête de course, mais ce modèle
http://www.norhtec.com/products/mcsr/index.html
ウィズコロナ
- [^] # Re: Quelle distrib ?
  
  Posté par octane le 07 avril 2009 à 12:38. Évalué à 2.
  
  Toutou linux est déjà optimisé pour un support USB...
  
  J'utilise une slackware12.2 sur un Acer Aspire One.
  
  Le chiffrement consomme pas mal (j'ai souvent le kcryptd dans les process qui s'affole). L'utilisation d'ext3 est abominable (mais vraiment, du genre tu t'endors avant la fin du boot). L'utilisation d'ext2 va bien.
  
  La lenteur était surtout ressentie avec firefox.
  J'ai fait des essais avec openoffice3, et pas de problèmes.
  J'ai encore des lenteurs au chargement de XFCE; mais au démarrage seulement, rien ensuite.
  
  J'hésite à mettre d'autres répertoires en tmpfs comme /var/run ou /var/lock, ou des journaux messages.
  - [^] # Re: Quelle distrib ?
    
    Posté par palm123 (site web personnel) le 07 avril 2009 à 13:08. Évalué à 3.
    
    Très bien ton script.
    
    Je suppose que tu as déjà lu
    http://petaramesh.org/post/2008/09/01/Noyau-2627-Ubuntu-cust(...)
    et
    http://petaramesh.org/post/2008/08/24/Noyau-Ubuntu-custom-po(...)
    
    qui parle aussi de performance sur ce modèle
    
    :-)
    ウィズコロナ
  - [^] # Re: Quelle distrib ?
    
    Posté par B16F4RV4RD1N le 07 avril 2009 à 15:35. Évalué à 2.
    
    c'est quoi l'intérêt du chiffrement de firefox ?
    
    Pourquoi ne pas chiffrer uniquement les données personnelles importantes ?
    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
    - [^] # Re: Quelle distrib ?
      
      Posté par octane le 07 avril 2009 à 16:55. Évalué à 4.
      
      c'est quoi l'intérêt du chiffrement de firefox ?
      
      Ce n'est pas firefox qui est chiffré, mais la clé USB. Donc de facto, firefox est situé sur un support chiffré.
      
      Je me suis inspiré d'un article de linux magazine qui parlait du chiffrement de disque sous linux. Absolument _tout_ est chiffré. Chiffrer /home m'apparait hautement insuffisant. On ne sait jamais ce que contient /tmp ou /var/tmp ou /var/spool par exemple.
      
      J'ai donc utilisé une clé USB de 4Go que j'ai coupé en deux:
      900Mo en VFAT (/dev/sda1) en clair (qui contient le chargeur de boot, le noyau et l'initramfs)
      le reste en ext2 chiffré (soit 2.8Go car les clés ne font pas 4Gio, mais 4Go)
      
      Je détecte au boot si sur le disque local il y a une partition SWAP. Si oui, je chiffre, je mkswap et je l'utilise (a l'extinction, je fais l'inverse, je ferme le device chiffré, et je refais un mkswap sur le device réél) [1]
      
      Donc absolument toute ma distribution est chiffrée, je peux utiliser la clé USB sur n'importe quelle machine (BSD, mac, et même windows, sisi) pour échanger des fichiers en clair à l'aide de la partition VFAT
      
      J'ai fait le choix du chiffrement pour pleins de raisons que je n'évoquerai pas ici, en sachant bien que ça impacterait un peu les perfs.
      
      [1] Cela peut poser des problèmes si je me branche sur une machine en hibernation. Le système est hiberné dans le swap, j'arrive, j'explose tout, je m'en vais, et le reboot de la machine d'origine passera mal :-)
      je m'en vais améliorer le truc. Question: comment savoir qu'une partition swap a servi pour hiberner un système?
# Dans mon cas

Posté par BohwaZ (site web personnel, Mastodon) le 08 avril 2009 à 00:16. Évalué à 1.

J'ai rencontré le même souci (dans le cadre d'une installation sur Compact Flash) mais j'ai abandonné firefox, par contre Opera semblait un peu trop écrire sur le disque même avec le cache disque désactivé (il devait synchroniser l'historique je présume), du coup je l'ai aussi mis sur un disque RAM, que je resynchronise à la fermeture, ce qui hélas prends pas mal de temps à faire le sync. Faudrait que je nettoie le .opera un de ces jours.

Bon en fait c'est pas ça dont je voulais parler. Mon souci premier c'est que ma debian semble avoir beaucoup de mal avec le disque en compact flash. Depuis quelques temps, la machine ne s'éteinds plus correctement, ça donne un écran noir et ça reste planté comme ça, je suis obligé de forcer le halt avec le bouton power. Du coup au prochain boot je me tape un check de la partoche et là c'est la catastrophe, ext2 est un système de fichiers qui semble extraordinairement mauvais. Souvent des fichiers disparaissent, voir des répertoires entiers. J'ai récemment perdu tous mes mails comme ça (heureusement que j'ai un backup).

Bon heu du coup si quelqu'un a un tuyau pour sécuriser un peu mieux mes données, je dis pas non...
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
- [^] # Re: Dans mon cas
  
  Posté par Nicolas Boulay (site web personnel) le 08 avril 2009 à 11:32. Évalué à 1.
  
  Utilises ext3 déjà. Ensuite, il faut être sûr de sa CF et de savoir les modes de transfert qu'elle supporte correctement.
  "La première sécurité est la liberté"
  - [^] # Re: Dans mon cas
    
    Posté par octane le 08 avril 2009 à 16:28. Évalué à 2.
    
    Utilises ext3
    
    Been there, done that.
    Comme indiqué, la batterie à le temps de se vider que l'écran de login n'est pas arrivé. C'est inexploitable. Complètement.
    
    De plus, l'écriture du journal risque de "tuer" extremement rapidement la flash. C'est un fichier, situé toujours à la même place qui est écrit en permanence.
    (ext4 améliore ce point, à ce sujet)
    
    Par contre, comment connaitre : les modes de transfert qu'elle [la clé USB] supporte correctement ? Là, ça m'intéresse.
    - [^] # Re: Dans mon cas
      
      Posté par BohwaZ (site web personnel, Mastodon) le 08 avril 2009 à 17:23. Évalué à 1.
      
      Oui non ext3 c'est mauvais pour le support c'est clair.
      
      Pour les modes de transferts, je présume qu'il parle d'udma etc. Du coup un peu de hdparm -i /dev/hda te donnera les infos utiles. Par exemple là au bureau sur mon disque dur : UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
      
      L'étoile indique le mode utilisé en ce moment, si c'est pas le plus rapide c'est que y'a un souci (mais tu peux pas forcément y faire quelque chose).
      
      Enfin c'est pas de là que vient mon souci à moi je pense...
      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# ca marche bien...

Posté par NeoX le 08 avril 2009 à 01:36. Évalué à 3.

j'ai juste modifié ton script pour qu'il soit utilisable par tout utilisateur qui serait sudoer
mais qui ne voudrait pas modifier son /etc/fstab

ci-dessous la version (bavarde avec les echos et les tar *vf...)
#! /bin/bash #script fast firefox. L'idée est de mettre en RAM ~/.mozilla/firefox # 1. on sauvegarde tout sauf le Cache # 2. on monte le répertoire firefox en tmpfs # Pour cela, fstab doit contenir une ligne # tmpfs /home/octane/.mozilla/firefox tmpfs noauto,uid=octane,user,mode=700 0 0 # 3. on detarre le contenu qui se trouve donc en RAM # on optimise les bases sqlite3 # A la déco, on recommence, en sens inverse. # j'ajoute des xmessage afin d'expliquer ce que fait le script launch_ffirefox () { xmessage -center "Launching fast firefox.. Please Wait" & #checking if my little hack is not already in use if ! mount | grep "~/.mozilla/firefox" > /dev/null then #Good thing echo "tmpfs is not mounted" #checking if firefox is not in use if ps ax | grep firefox-bin | grep -v grep > /dev/null then #do nothing echo "do nothing" else #ok, time to go on ## optimizing sqlite database before backup for f in ~/.mozilla/firefox/*/*.sqlite; do sqlite3 $f 'VACUUM;'; done ## purging cache before backup cd ~/.mozilla rm -f firefox/Cache/* [ -f ff.tgz ] && rm ff.tgz ## backup tar cvfz ff.tgz firefox/ ## activating tmpfs (requiere sudo right) sudo mount -t tmpfs tmpfs ~/.mozilla/firefox tar xvfz ff.tgz ## real launch killall xmessage /usr/bin/firefox $@ fi else #do nothing echo "tmpfs is mounted" fi } cancel_ffirefox () { xmessage -center "Stopping firefox, please Wait.." & #We should have been launched by this script. ## purging cache cd ~/.mozilla/ rm -f firefox/Cache/* [ -f ff.tgz ] && rm ff.tgz ## backup of tmpfs tar cvfz ff.tgz firefox/ ## deactivating tmpfs umount ~/.mozilla/firefox ## restore firefox files tar xvfz ff.tgz killall xmessage } #Now we can launch this script launch_ffirefox cancel_ffirefox
- [^] # Re: ca marche bien...
  
  Posté par NeoX le 08 avril 2009 à 01:53. Évalué à 2.
  
  evidemment vous aurez corrigé la ligne
  ## deactivating tmpfs umount ~/.mozilla/firefox
  
  en
  ## deactivating tmpfs sudoumount ~/.mozilla/firefox
  
  ca sinon ca ne demonte pas le tmpfs
# très bien mais...

Posté par solsTiCe (site web personnel) le 12 avril 2009 à 17:45. Évalué à 2.

c'est super ce script. je vais commencer à l'essayer même sur mon desktop parce que ça commence à me prendre la tête les 3 secondes 5 secondes parfois 10 secondes d'attente en surfant dès qu'il y a un peu d'IO en cours quand je surfe qui fait bloquer firefox...

moi j'ai ~/.mozilla/firefox/"uncode".default/Cache

donc j'ai du changer la ligne
rm -f firefox/Cache/*
en
rm -f firefox/*/Cache/*

j'aime pas xmessage. pouah... rien du tout c'est aussi bien.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.