Linux et les disques durs… suite et fin ?

L’histoire de lag des disques durs, c’est à présent le fil rouge de mon blog. Sur google maps, sous Chromium (et Firefox aussi bien sûr), cela rame comme pas possible, pourtant, j’aurai bien aimé que ce soit comme Windows, aucune activité de disque significative (par déduction, les données manipulées sont en RAM). Comme cela m’a vraiment gavé, que les optimisations (nobarrier,data=writeback,noatime et companie) n’y change rien, j’ai sorti l’artillerie lourde block_dump. Un bel outil de bourrin pour linux qui affiche tout se qui se passe sur les disques durs. Autant que c’est vraiment pour du débogage de désespoir car il n’existe aucun outil comme filemon sur linux (inotifywatch -r ahah).

Après avoir activé l’outil, je vois énormément de flush-8:16 et jbd2. Génial, mais je les voyais déjà avec iotop. Sauf que cette fois-ci, je peux voir l’application à l’origine de ces appels. Puis j’arrive finalement à une très longue série de:

Jul 7 23:39:41 localhost kernel: [40813.222707] Chrome_CacheThr(1237): READ block 49119816 on sdb5 (8 sectors)
Jul 7 23:39:41 localhost kernel: [40813.222912] Chrome_CacheThr(1237): READ block 49119824 on sdb5 (8 sectors)

sdb étant mon second disque dur pour /home, j’en déduis que chromium met en cache les données dans /home… ahaha ? étonnant car je vois aussi beaucoup d’accès à tmpfs.

Jul 7 23:47:48 localhost kernel: [41298.459319] Chrome_IOThread(1238): dirtied inode 105835 (?) on tmpfs
Jul 7 23:47:48 localhost kernel: [41298.513204] Chrome_IOThread(1238): dirtied inode 105837 (?) on tmpfs

Mais ceux-ci ne se produisent pas au moment du lag, et en plus l’exemple est mal choisi car c’est seulement du dirtied. Un autre exemple dans un autre lag:

Jul 7 23:49:53 localhost kernel: [41422.756314] Chrome_CacheThr(1237): READ block 49050968 on sdb5 (8 sectors)
Jul 7 23:49:53 localhost kernel: [41422.756494] Chrome_CacheThr(1237): READ block 49050976 on sdb5 (8 sectors)
Jul 7 23:49:53 localhost kernel: [41422.756649] Chrome_CacheThr(1237): READ block 49050984 on sdb5 (8 sectors)
Jul 7 23:49:53 localhost kernel: [41422.817261] Chrome_IOThread(1238): dirtied inode 104017 (?) on tmpfs
Jul 7 23:49:53 localhost kernel: [41422.820708] Chrome_IOThread(1238): dirtied inode 106735 (?) on tmpfs
Jul 7 23:49:53 localhost kernel: [41422.825369] Chrome_IOThread(1238): dirtied inode 106736 (?) on tmpfs
Jul 7 23:49:53 localhost kernel: [41422.825656] Chrome_CacheThr(1237): READ block 49050992 on sdb5 (8 sectors)

En cherchant comment mettre en RAM le cache, je trouve la solution sur le wiki de ma distribution. Mettre le cache en RAM, c’est tellement plus pratique que ce ne soit pas le comportement par défaut pour forcer les gens à trouver la solution eux-même… LINUX!!

Bon après, c’est peut-être parce que le cache en RAM de Chromium est complet qu’il utilise le disque dur (mais j’en doute). Cela provoque des comportements totalement débile que l’on ne rencontre pas sur Windows. Mais le plus étonnant dans tout ça, c’est qu’avant cela ne le faisait pas, c’est venu d’un coup, enfin suite à une mise à jour bien sûr, mais impossible de dire laquelle car le problème n’a pas été rapidement identifié.

Je suppose que pour firefox c’est le même combat. En regardant la solution, elle est pire, il y a une page dédiée à cela, qui concerne tout le profil de firefox mis en RAM (et pas seulement le cache). Avec un script de synchronisation entre la RAM et le système de fichier, avec une CRON pour synchroniser régulièrement… OH STOP, si il faut faire tout ça pour avoir un firefox fluide, c’est hors de question, je reste sur Chromium.

Finalement je trouve cet article, qui permet de changer le dossier de cache seulement. Je me suis retrouvé avec un firefox rapide… non il ne faut pas déconner xD Mais relativement plus rapide qu’avant c’est sûr.

Sincérement, le navigateur est de nos jours généralement le logiciel le plus utilisé sur un desktop, n’avoir ni firefox, ni chromium de correctement configuré par défaut est catastrophique. Mais c’est linux, c’est normal 🙂

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :