web-dev-qa-db-fra.com

Blocage de Firefox avec l'utilisation du processeur à 100% pendant 30 secondes lors du lancement de Chromium

Récemment, j'ai commencé à observer ce comportement très déroutant et énervant, pour ne pas dire inquiétant, lorsque Firefox était ouvert puis lancé dans Chromium:

Pendant environ 30 secondes, les processus enfants de Firefox consommeraient toutes les ressources de calcul disponibles, ce qui entraînerait l'arrêt du rendu des sites Web (pages déjà affichées figées, les nouvelles pages affichant une page blanche avec un cercle gris) alors que la fenêtre entière est toujours réactive (menus, défilement de page) , changer d’onglet, même des pages internes comme about: config ou about: les préférences fonctionnent ...). Le chrome lui-même ne présente aucun symptôme. Terminer le chrome à nouveau immédiatement, pendant que Firefox tourne, n'arrête pas le comportement plus rapidement.

La même chose se produit avec mon profil Firefox habituel, un tout nouveau profil Firefox sans add-ons, etc., Firefox a démarré en mode sans échec avec les add-ons désactivés et Firefox a démarré en mode privé. Semblable pour Chromium, je peux le lancer avec mon profil habituel, en mode incognito ou avec un profil temporaire, générant toujours les mêmes résultats.

Il n'y a rien d'étrange à se passer lorsque Chromium est en cours d'exécution et que j'ouvre Firefox.

Lors du lancement de Firefox depuis un terminal, je reçois parfois des messages comme ceux-ci lorsque je le quitte en cours de rotation (remarquez la ligne d'erreur de tuyau mentionnant du chrome ipc ...):

ExceptionHandler::GenerateDump cloned child 32165
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
[Parent 26520, Gecko_IOThread] WARNING: pipe error (52): Connection reset by peer: file /build/firefox-8oo9jx/firefox-62.0+build2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
ExceptionHandler::GenerateDump cloned child 32274
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child

Étrangement, je ne pouvais pas reproduire ce comportement dans un compte invité ou dans un compte régulier (admin) nouvellement créé.

Quelques spécifications du système (mises à jour):

  • Ubuntu 16.04 (64 bits)
  • Firefox 62.0 + build2-0ubuntu0.16.04.5 63.0 + build2-0ubuntu0.16.04.2
  • Chrome 69.0.3497.81-0ubuntu0.16.04.1 70.0.3538.77-0ubuntu0.16.04.1
  • fontconfig 2.11.94-0ubuntu1.1
  • Matériel graphique: Carte graphique intégrée Intel SkyLake (i5-6200U) + Nvidia GeForce 940M
    Actuellement, le pilote nvidia-410 est installé, mais je suis passé au profil principal Intel. Comment puis-je résoudre et résoudre ce problème?

J'ai créé un profil de performances avec Gecko Profiler Extension, installé dans un profil Firefox frais et vierge sur mon compte Ubuntu habituel. Vous pouvez le trouver ici: https://perfht.ml/2zpTWsh - Le délai d'inactivité avec une utilisation de 100% du processeur doit correspondre approximativement à la zone mise en surbrillance dans les chronologies de Content Proc, d'environ 18 à 56 secondes. .

J'ai créé un rapport de bogue sur Mozilla pour ce problème: https://bugzilla.mozilla.org/show_bug.cgi?id=1504461

Mise à jour importante: Apparemment, mon rapport de bogue était une copie de https://bugzilla.mozilla.org/show_bug.cgi?id=149590 , qui indique fontconfig en tant que coupable. On dirait que démarrer Chromium modifie d'une manière ou d'une autre la configuration des polices, ce qui déclenche un rechargement complet dans Firefox. Cela correspond au rapport de profilage des performances et à la manière dont les mises à jour antérieures des packages de polices ont déclenché le même type de blocage.

Avez-vous des idées pour que les trois (Firefox, Chromium, fontconfig) se comportent bien les uns avec les autres?

firefoxfontschromiumperformance
16
Byte Commander

TL; DR: Il s'agit d'un problème avec fontconfig avant la version 2.13. Il peut être corrigé en mettant à jour le paquet à la version 2.13 ou supérieure (bien que je n’aie pas trouvé de fournisseur approprié). Vous pouvez également examiner tous les dossiers liés aux polices et les fichiers de configuration de votre répertoire personnel et vérifier si leur suppression résout votre problème. Pour moi, renommer ~/.fonts a fonctionné.

Après avoir pris connaissance des rapports de bogues https://bugzilla.mozilla.org/show_bug.cgi?id=14959 et https://bugzilla.mozilla.org/show_bug.cgi?id = 1411338 Il devient assez clair que le problème doit être causé par fontconfig.

En quelque sorte, au démarrage, Chromium déclenche une modification de la base de données de polices (???), ce qui oblige Firefox - s'il est en cours d'exécution - à ré-analyser le système de fichiers à la recherche de polices, ce qui entraîne l'utilisation du processeur et un gel temporaire.

Apparemment, la mise à jour du paquet fontconfig de la version 2.11 à la version 2.13 (version fournie par exemple dans Ubuntu 18.10) devrait résoudre le problème, mais je n’ai trouvé aucun moyen facile d’obtenir cette version le 16.04 sans rompre les dépendances de nombreux autres packages que j’ai installés.

Par conséquent, le problème étant limité à mon compte d'utilisateur, j'ai examiné la configuration des polices et des dossiers locaux de l'utilisateur. Pour être honnête, il existe tout un tas de répertoires liés aux polices, dont ~/.fonts, ~/.local/share/fonts, ~/.local/share-font-manager, ~/.config/font-manager, ~/.cache/font-manager, ~/.cache/fontconfig et quelques autres fichiers de configuration et polices spécifiques à l’application.

J'ai commencé par supprimer (renommer) le dossier ~/.fonts, car il ne semblait pas contenir quoi que ce soit d'utile, et un simple touch ~/.fonts/Library/ auparavant qui a déclenché l'inconduite de Firefox. Après le retrait de ce dossier, le problème lors du lancement de Chromium a également évolué.\o /

11
Byte Commander

Contexte

Il a été proposé ce bogue Firefox 1492360: tilisation élevée du processeur lors de l’ouverture de firefox avant chrome/chrome . Il s’agit d’un doublon du bogue 1495900: Le démarrage de Chrome rend les processus de contenu Firefox bloqués pendant environ deux minutes, en raison de la nouvelle analyse de la police FontConfig (FcInitReinitialize) , est le coupable.

Mais je suis aussi sur Firefox:

Firefox version.png

Et quand j'ouvre Chrome:

Chrome version.png

Je ne vois aucune performance affectée par les processeurs.

Cela peut aller à l’encontre de votre morale, mais vous pouvez peut-être essayer d’installer google-chrome-stable comme moi. Puis refait le test. S'il n'y a pas de pic d'utilisation du processeur à 100%, un rapport de bogue peut être archivé entre Chrome et Chrome.

Je suis sur Ubuntu 16.04.5 LTS. Bien que le noyau soit actuellement 4.14.78 chaîne LTS, je ne pense pas que cela y soit pour quelque chose, car je n'ai pas remarqué de problèmes de processeur sur les noyaux précédents.

La seule fois où je vois tous les processeurs à 100%, c'est pendant update-initramfs.

fontconfig verson

Dans le rapport de bogue, il est révélé:

$ dpkg -l 'fontconfig*' | grep "^ii"
ii  fontconfig        2.12.6-0ubuntu2 AMD64        generic font configuration library - support binaries
ii  fontconfig-config 2.12.6-0ubuntu2 all          generic font configuration library - configuration

Dans ma version non-buggy (peut-être en raison de l'absence de polices locales):

$ dpkg -l 'fontconfig*' | grep "^ii"
ii  fontconfig        2.11.94-0ubuntu1.1 AMD64        generic font configuration library - support binaries
ii  fontconfig-config 2.11.94-0ubuntu1.1 all          generic font configuration library - configuration

Je suis à la version 2.11.94 antérieure au rapport de bogue 2.12 version. Dans les rapports de bogues, la mise à niveau vers 2.13 est une solution recommandée, mais l'OP mentionné dans les commentaires n'est pas possible. En tant que tel, 2.11.94 pourrait être une option.

1
WinEunuuchs2Unix

La performance de Bumblebee est connue pour être relativement buggy. nvidia-prime est connu pour vider les batteries des ordinateurs portables. Cochez ces deux options, celle qui fonctionne ou qui convient le mieux à votre système, soit Nvidia avec Bumblebee ou nvidia-prime. Vérifiez ce qui fonctionne le mieux avec l'activation ou la désactivation des graphiques discrets Nvidia.

0
karel

À en juger par le journal, il semble que Firefox utilise le IPC (communication entre processus) synchrone pour une raison quelconque. Il existe dans Firefox des indicateurs permettant d'activer explicitement le IPC synchrone (par exemple: network.cookie.ipc.sync). Un de ceux-ci pourrait être activé. Vous pouvez y accéder depuis la page about: config

Le retard serait alors le résultat de l'attente de firefox sur la réponse. Puisqu'il n'y a pas de charge lorsque Chromium a fini de démarrer ou n'est pas en cours d'exécution, il y a une réponse immédiate.

Connexes: https://bugzilla.mozilla.org/show_bug.cgi?id=133168

0
Aswin B

Je ne sais pas si la suggestion suivante fonctionnera ou non. Vous pouvez essayer. Essayez de supprimer complètement le chrome et Firefox (conservez bien entendu les fichiers .deb) à l’aide de Synaptic Package Manager. Après cela, vérifiez s'il y a des dépendances brisées. Fixez-les en utilisant synaptique (le cas échéant). Maintenant, vérifiez l’utilisation du processeur (j'utilise Powertop) .Faites enfin une nouvelle réinstallation des navigateurs.

Note: Ces choses sont généralement ce que je fais en cas d’anomalies spécifiques. Je me souviens avoir fait face à un problème légèrement similaire il y a un an. Cela a été résolu de cette façon.

0
Hirak