Salut,
Comment arriver à déterminer précisément ce qui provoque la fièvre du CPU ?
Réponse : avec l’enregistrement des performances
Salut,
Comment arriver à déterminer précisément ce qui provoque la fièvre du CPU ?
Réponse : avec l’enregistrement des performances
de la façon habituel en démarrant sur un profil vierge et ajoutant les plugin/addon les un après les autres et vérifiant que ce ne soit pas un souci d’utilisation de ressources du GPU par exemple.
Mais sans plus d’explications c’est compliqué à dire, surtout que ça fait déjà quelques temps que j’ai passé l’ensemble des navigateurs sous quantum en mixant le plus proprement possible le fichier de sources (enfin la libc j’y ai pas coupé ).
Je ne cherche pas une réponse mais une méthode pour traquer la cause…
Ce n’est pas permanent mais quand ça arrive c’est reproductible avec firefox esr 52 sur stretch ou 60 sur franken-stretch (stretch plus des bouts de sid et experimental pour ff esr 60).
J’ai naïvement cru que ff esr 60 ne serait pas sensible mais en fait, en l’état, il l’est.
Affichage -> Style de la page -> Aucun style
La fièvre redescend mais le site est inutilisable !
Est-ce pour autant que CSS est responsable ? Pas sûr
Basculer sur un nouvel onglet vide fait aussi baisser la fièvre donc le rendu est en cause mais ça ne dit pas pourquoi.
Salut
Je préfère installer l’archive Firefox de Mozilla en local, je ne vois pas la plus value de Debian pour Firefox
on peut avoir des infos par firefox lui meme
about:support
about:performance
pour Firefox 61, atop me dit
PID SYSCPU USRCPU VGROW RGROW ST EXC THR S CPUNR CPU CMD 1/3
8607 0.10s 0.62s 0K -20K -- - 13 S 0 7% gnome-shell
6978 0.16s 0.39s 0K 0K -- - 6 S 0 5% Xorg
11214 0.10s 0.20s 0K 112K -- - 4 S 0 3% gnome-terminal
10810 0.08s 0.21s 0K 140K -- - 61 S 0 3% firefox
3184 0.07s 0.00s 0K 0K -- - 3 S 1 1% iio-sensor-pro
10874 0.02s 0.04s 0K 0K -- - 17 S 0 1% Web Content
8905 0.01s 0.03s 0K -100K -- - 31 S 0 0% chromium
10785 0.00s 0.03s 0K 0K -- - 14 S 0 0% chromium
11226 0.02s 0.01s 20K -116K -- - 1 R 1 0% atop
10682 0.02s 0.00s 0K 0K -- - 1 I 1 0% kworker/1:2
Quelle utilisation, site, videos t’amene a exploser la cpu??
La page d’accueil de google mais pas toutes les pages de google. Certaines recherches sont possibles, d’autres maintiennent la fièvre.
Peu importe les sites concernés, je voudrais une méthode pour faire la chasse au réchauffement
about:performance ne se rend compte de rien !
tout est vert
EDIT
Le délai de 10 secondes fait que ça prend un certain temps avant de changer de couleur. Mea culpa.
compare avec un firefox en local
non désolé
j’ai déjà deux éléments de comparaisons reproductibles
je souhaite uniquement connaître une approche pour traquer la source de chaleur
La première source comme évoqué au-dessus sont les thèmes et plugins (méthode tous les désactiver puis les réactiver un part un)
Ensuite la seconde source c’est le contenu, si tu a un fort rendu graphique et que tu subi des pointes de cpu vérifie que les accélérations matériels sont activé. Sinon cela peut également provenir des scripts présent sur la page (tente de désactivé js sur ta page (ctrl + maj + c setting a droite ( l’engrenage) puis désactiver le javascript) si cela réduit la consommation il te faut débugger tes scripts si tu en ai responsable ou déposer un ticket au webmaster.
Ya moyens que tu drop le lien de la page fautive ?
tout ce que je peux dire c’est que firefox 61 et firefox nightly installés en local fonctionnent très bien.
donc 3 pistes
J’opte pour l’utilisateur
L’utilisateur utilise firefox depuis netscape
L’utilisateur est taquin et insiste : il n’est pas responsable de la montée en charge car la situation est reproductible avec ff 52 stretch et ff 60 franken-stretch (dans une kVM certes) avec une simple page d’accueil google en safe-mode
Pour rappel : désactiver les styles remet les choses en ordre.
L’utilisateur apprécie les pistes configuration matérielle et graphique mais la question demeure la même depuis le début : comment le vérifier ?
Pire : pourquoi l’indicateur de performance interne ne s’aperçoit-il de rien alors qu’un simple top affiche clairement la couleur (rouge) ?
NB : l’utilisateur a pris la grosse tête donc il parle de lui à la troisième personne.
Je vais me reprendre
EDIT
Commençons par le CPU :
$ lscpu
Architecture : x86_64
Mode(s) opératoire(s) des processeurs : 32-bit, 64-bit
Boutisme : Little Endian
Processeur(s) : 2
Liste de processeur(s) en ligne : 0,1
Thread(s) par cœur : 1
Cœur(s) par socket : 2
Socket(s) : 1
Nœud(s) NUMA : 1
Identifiant constructeur : AuthenticAMD
Famille de processeur : 15
Modèle : 72
Nom de modèle : AMD Turion(tm) 64 X2 Mobile Technology TL-50
Révision : 2
Vitesse du processeur en MHz : 800.000
Vitesse maximale du processeur en MHz : 1600,0000
Vitesse minimale du processeur en MHz : 800,0000
BogoMIPS : 1596.02
Virtualisation : AMD-V
Cache L1d : 64K
Cache L1i : 64K
Cache L2 : 256K
Nœud NUMA 0 de processeur(s) : 0,1
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl extd_apicid eagerfpu pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch vmmcall
Les histoires de style, de css , de rendu des pages ç’est sensé avoir été amélioré depuis Firefox 57 quantum mais c’est bien trop compliqué pour moi
https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/
ça dépends forcément d’une incapacité de ton PC ou d’un mauvais réglage puisque tu es le seul à t’en plaindre, j’ai pas vu de levée de boucliers sur les forum depuis firefox 57 quantum
Quel interet à s’arc-bouter sur un vieux Firefox dépassé
Je suis le premier à avoir espéré que ff esr 60 soit plus frais pour le bien du matériel
Précision : ce “problème” n’existait pas avec ff esr 45 donc quelque chose est apparu entre 45 et 52 mais quoi ?
y a plus qu’a éplucher les releases notes
C’est fort possible mais comment mettre le doigt dessus, c’est la question initiale.
EDIT
Profil tout neuf, en safe-mode, page d’accueil google et Web Content qui chauffe
4390 firefox-esr -P chaud --safe-mode
4439 /usr/lib/firefox-esr/plugin-container -safeMode -greomni /usr/lib/firefox-esr/omni.ja -appomni /usr/lib/firefox-esr/browser/omni.ja -appdir /usr/lib/firefox-esr/browser 4390 true tab
EDIT 2
Quelqu’un connaît-il ce sujet ?
Liens profonds et technologies web
Des techniques et des bibliothèques bien connues comme SWFAddress et Unfocus History Keeper peuvent être utilisées par les utilisateurs de Flash ou AJAX pour rendre possible l’utilisation de liens profonds vers des pages de leurs sites.
EDIT 3
Nouveau test avec une kVM buster à jour et ff esr 60 issu d’experimental : même résultat.
Google mine des bitcoins ou bien ?
Peut etre que la compilation Debian et ce qui est ajouté ne convient pas à ton environnement??
comme le champagne , le brut c’est meilleur
je te redirai bien d’essayer avec le firefox brut de fonderie de Mozilla installé en local mais bon je sens qu’il y a de la résistance
On est sur le forum debian-fr pas sur le forum mozilla-fr.
Je ne cherche pas spécialement à aider mozilla mais plutôt à comprendre ce qu’il se passe, oui, dans debian, dans mon cas.
Qui sait ? Peut-être que ce sera révélateur de quelque chose ?
EDIT
À propos d’intégration système (ce que fait debian), le changelog de firefox montre les entrées et sorties qu’ont fait les libs nspr, nss et sqlite.
Par phase, les libs systèmes ont été utilisées et à d’autres périodes les libs fournies par le paquet.
buster ambitionne de remettre l’utilisation des libs sytème (debian donc).
Le problème semble bien venir de CSS.
Procédé comme suit :
page d’accueil google
Affichage -> Style de la page -> Aucun style
Outils -> Développement web -> Performances
Lancer l’enregistrement des performances
Affichage -> Style de la page -> Style de base de la page
et c’est parti !
J’ai des cycles interminables de Paint | Recalcul des styles
Cause de recalcul : CSSAnimations
Le mystère est élucidé mais quelle est donc cette animation invisible ?
L’outil utilisé permet bien de détecter ce qui consomme.