Iceweasel : utilisation CPU trop importante

Support Debian
#1

Salut,

Depuis quelques jours mon Iceweasel (version 13 quand le problème est apparu, maintenant version 14 sans amélioration) s’est mis à consommer du CPU de manière anormale. Aucune mise à jour suspecte dans mes logs d’aptitude (avec Wheezy en freeze c’est plutôt calme en ce moment…).
Ça me le fait même lorsque je me limite à des sites sûrs (genre debian-fr).
J’ai créé un nouveau profil pour tester, ça semble résoudre le problème. Conclusion : ça vient sûrement d’une de mes extensions.

Problème : la charge CPU monte tout doucement au fur et à mesure de l’utilisation, ça ne devient vraiment détectable qu’au bout de 30mn. Comme j’ai quand même pas mal d’extensions, ça va être très pénible de jouer à les désactiver une par une étant donné le temps qu’il faut pour que le problème réapparaisse.

Question : y a-t-il des outils pour voir en détail ce qui se passe dans Firefox/Iceweasel (un peu comme top mais dédié aux “process internes” de FF/IW) ?
D’autres idées pour identifier rapidement le coupable sans avoir à désactiver ma 30aine d’extensions une par une et attendre 30mn à chaque fois ?

#2

Salut;

Rappel : Le principe cartésien se nomme la dichotomie
30 ==> 15
15 ==> 7/8
4 ==> 2
1
Soit 4 manœuvres

#3

[quote=“ggoodluck47”]Salut;

Rappel : Le principe cartésien se nomme la dichotomie
30 ==> 15
15 ==> 7/8
4 ==> 2
1
Soit 4 manœuvres[/quote]
Tu as oublié 8 => 4 et tu dois multiplier par 2 si tu n’es pas de bol, soit 10 manoeuvres…
(15 15 7 8 4 4 2 2 1 et 1 pour vérifier)

ps x -H plus des kills bien faits devait fonctionner non? En général ce sont des processsus genre flash ou des scripts qui ne terminent pas…

#4

Firefox ne possède pas de ‘top’ interne, par contre il possède un moniteur de consommation mémoire sur la page ‘about:memory’.
En activant le mode verbose ‘about:memory?verbose’, on peut voir la consommation de chaque extension chargée, ça peut être une piste pour tracer celle qui pose problème.

#5

Salut,

:blush: J’ai oublié 8 ==> 4 mais quand la panne n’apparait pas c’est qu’il faut choisir de continuer à tester sur le paquet que l’on a délaissé :slightly_smiling:

#6

Hum, dans ce genre de cas je vérifie avant de continuer mais sur le principe tu as raison, ça peut ramener à 6 manoeuvres max (en tenant compte de la vérification finale).

Sinon je ne connaissais pas about:memory. Quelqu’un connait une liste des about complètes où il faut regarder le code de firefox?

[edit: trouver en faisant about:help (rien) puis about:about (bingo!))

#7

[quote=“fran.b”][quote=“ggoodluck47”]Salut;

Rappel : Le principe cartésien se nomme la dichotomie
30 ==> 15
15 ==> 7/8
4 ==> 2
1
Soit 4 manœuvres[/quote]
Tu as oublié 8 => 4 et tu dois multiplier par 2 si tu n’es pas de bol, soit 10 manoeuvres…
(15 15 7 8 4 4 2 2 1 et 1 pour vérifier)

ps x -H plus des kills bien faits devait fonctionner non? En général ce sont des processsus genre flash ou des scripts qui ne terminent pas…[/quote]
Pourquoi ?

#8

Salut,

Merci pour vos réponses effectivement j’avais pas pensé à la dichotomie (pourtant je devrais connaître le principe depuis le temps… :blush:).
Je suis en train de m’en occuper…

#9

Bon j’ai trouvé le coupable (Google Search by Image).

Pour info j’ai un peu accéléré le processus en augmentant mon /sys/devices/system/cpu/cpufreq/ondemand/up_threshold (normalement mon CPU change de fréquence très rapidement pour avoir une bonne réactivité – en augmentant le up_treshold le CPU reste à fréquence minimale, donc à opérations égales il doit tourner plus longtemps ce qui augmente la charge visible et rend le problème plus facile à constater).

En fait l’extension de recherche d’images Google augmentait légèrement la charge CPU à chaque page visitée, sans “rendre” le CPU même si la page était ensuite fermée. Saloperie.

#10

Vincent n’est pas mort !
Vous savez comment on appelle les “nouveaux envahisseurs” ?
.
.
.

  • Google :confused: