90% de cpu dans flash ...
Le
Léo
Bonjour,
Depuis quelques mois je constatais des 100% de cpu dans le navigateur
multi-onglets sans parvenir à en trouver la cause
J'incriminais la Java Virtual Machine de Sun qui est utilisé intensément
par les pages de Boursorama pour afficher des cours de bourse en temps-réel
dont j'imaginais qu'elle supportait mal d'être instanciée dans plusieurs
page à la fois Les pages se gênaient et s'attendaient en accédant à des
ressources partagées
En y regardant d'un peu plus près avec le Process Explorer (de
sysinternals) je constate qu'à chaque fois, le stack du thread qui prend la
cpu est en train de servir le module flash ça dure typiquement plusieurs
minutes et ça finit par revenir à la normale (quand je ne cède pas à
l'impatience en tuant le process)
Je suspectais donc Flash (d'autant que j'avais lu il y a bien des mois
qu'il y avait une erreur dans les droits d'accès dans la base de registres
relatif à Flash. La manip au niveau de la BdR me semblant très technique je
ne m'y étais pas risqué) Même hypothèses que pour la JVM, cohabitation
difficile de plusieurs instances de l'objet Flash dans plusieurs pages du
même process ou même cohabitation difficile entre Flash et JVM
Je suis donc passé hier à la dernière version de Flash (après
désinstallation préalable de la version précédente 9.0.28 je crois), sans
que cela ne résolve cette question
Exemples typiques de stack dans cet état d'attente active
1)
ntoskrnl.exe+0x48f3
Flash9c.ocx+0x5925a
Flash9c.ocx+0x8c238
Flash9c.ocx+0x603f7
2)
ntoskrnl.exe+0x48f3
Flash9c.ocx+0x5e0a3
3)
ntoskrnl.exe+0x48f3
Flash9c.ocx+0x564b6
Flash9c.ocx+0x78b58
4)
ntoskrnl.exe!KiDispatchInterrupt+0x7f
Flash9c.ocx+0x8be1f
Flash9c.ocx+0x603f7
5) Exemple plus corsé (ce qui montre que ça vit et que ça évolue)
ntoskrnl.exe!KiDispatchInterrupt+0x7f
URLMON.DLL!CoInternetQueryInfo+0x26cb
URLMON.DLL!CoInternetQueryInfo+0x280a
URLMON.DLL!CoInternetQueryInfo+0x270e
URLMON.DLL!RegisterBindStatusCallback+0xb4d
URLMON.DLL!RegisterBindStatusCallback+0xadd
URLMON.DLL!RegisterBindStatusCallback+0x982
URLMON.DLL!RegisterBindStatusCallback+0x8b8
URLMON.DLL!CreateURLMonikerEx2+0x8f6
URLMON.DLL!CreateURLMonikerEx2+0xcea
Flash9c.ocx+0x9e9fa
Flash9c.ocx+0x9f589
Flash9c.ocx+0x8c935
Flash9c.ocx+0x90bab
Flash9c.ocx+0x90e59
Flash9c.ocx+0x910b5
Flash9c.ocx+0x91109
Flash9c.ocx+0xe0dc7
6) Corsé (toujours dans la même session de ce processus, ça dure depuis le
début de la rédaction de ce post)
ntoskrnl.exe!ExReleaseResourceLite+0x1a3
ntoskrnl.exe!NtWaitForSingleObject+0x94
ntoskrnl.exe!ZwYieldExecution+0xb78
ntdll.dll!KiFastSystemCallRet
kernel32.dll!WaitForSingleObject+0x12
URLMON.DLL!ReleaseBindInfo+0x431
URLMON.DLL!CreateUriPriv+0xbd
URLMON.DLL!CreateUriWithFragment+0x1e
URLMON.DLL!CreateUri+0x18
URLMON.DLL!CoInternetCombineUrl+0x5a
mshtml.dll!DllGetClassObject+0x2bdfb
mshtml.dll+0x2e339f
Flash9c.ocx+0xb7f11
Flash9c.ocx+0xb0bc7
J'ai l'impression que ces pubs flash souhaitent communiquer avec un
serveur pour leur raconter ce qui se passe chez moi (mais TCPView ne montre
pas de connections suspectes)
En savez-vous plus ?
Merci aux pros (!)
--
Léo
(http://www.cerber mail.com/?Nd39r1gp1C)
Depuis quelques mois je constatais des 100% de cpu dans le navigateur
multi-onglets sans parvenir à en trouver la cause
J'incriminais la Java Virtual Machine de Sun qui est utilisé intensément
par les pages de Boursorama pour afficher des cours de bourse en temps-réel
dont j'imaginais qu'elle supportait mal d'être instanciée dans plusieurs
page à la fois Les pages se gênaient et s'attendaient en accédant à des
ressources partagées
En y regardant d'un peu plus près avec le Process Explorer (de
sysinternals) je constate qu'à chaque fois, le stack du thread qui prend la
cpu est en train de servir le module flash ça dure typiquement plusieurs
minutes et ça finit par revenir à la normale (quand je ne cède pas à
l'impatience en tuant le process)
Je suspectais donc Flash (d'autant que j'avais lu il y a bien des mois
qu'il y avait une erreur dans les droits d'accès dans la base de registres
relatif à Flash. La manip au niveau de la BdR me semblant très technique je
ne m'y étais pas risqué) Même hypothèses que pour la JVM, cohabitation
difficile de plusieurs instances de l'objet Flash dans plusieurs pages du
même process ou même cohabitation difficile entre Flash et JVM
Je suis donc passé hier à la dernière version de Flash (après
désinstallation préalable de la version précédente 9.0.28 je crois), sans
que cela ne résolve cette question
Exemples typiques de stack dans cet état d'attente active
1)
ntoskrnl.exe+0x48f3
Flash9c.ocx+0x5925a
Flash9c.ocx+0x8c238
Flash9c.ocx+0x603f7
2)
ntoskrnl.exe+0x48f3
Flash9c.ocx+0x5e0a3
3)
ntoskrnl.exe+0x48f3
Flash9c.ocx+0x564b6
Flash9c.ocx+0x78b58
4)
ntoskrnl.exe!KiDispatchInterrupt+0x7f
Flash9c.ocx+0x8be1f
Flash9c.ocx+0x603f7
5) Exemple plus corsé (ce qui montre que ça vit et que ça évolue)
ntoskrnl.exe!KiDispatchInterrupt+0x7f
URLMON.DLL!CoInternetQueryInfo+0x26cb
URLMON.DLL!CoInternetQueryInfo+0x280a
URLMON.DLL!CoInternetQueryInfo+0x270e
URLMON.DLL!RegisterBindStatusCallback+0xb4d
URLMON.DLL!RegisterBindStatusCallback+0xadd
URLMON.DLL!RegisterBindStatusCallback+0x982
URLMON.DLL!RegisterBindStatusCallback+0x8b8
URLMON.DLL!CreateURLMonikerEx2+0x8f6
URLMON.DLL!CreateURLMonikerEx2+0xcea
Flash9c.ocx+0x9e9fa
Flash9c.ocx+0x9f589
Flash9c.ocx+0x8c935
Flash9c.ocx+0x90bab
Flash9c.ocx+0x90e59
Flash9c.ocx+0x910b5
Flash9c.ocx+0x91109
Flash9c.ocx+0xe0dc7
6) Corsé (toujours dans la même session de ce processus, ça dure depuis le
début de la rédaction de ce post)
ntoskrnl.exe!ExReleaseResourceLite+0x1a3
ntoskrnl.exe!NtWaitForSingleObject+0x94
ntoskrnl.exe!ZwYieldExecution+0xb78
ntdll.dll!KiFastSystemCallRet
kernel32.dll!WaitForSingleObject+0x12
URLMON.DLL!ReleaseBindInfo+0x431
URLMON.DLL!CreateUriPriv+0xbd
URLMON.DLL!CreateUriWithFragment+0x1e
URLMON.DLL!CreateUri+0x18
URLMON.DLL!CoInternetCombineUrl+0x5a
mshtml.dll!DllGetClassObject+0x2bdfb
mshtml.dll+0x2e339f
Flash9c.ocx+0xb7f11
Flash9c.ocx+0xb0bc7
J'ai l'impression que ces pubs flash souhaitent communiquer avec un
serveur pour leur raconter ce qui se passe chez moi (mais TCPView ne montre
pas de connections suspectes)
En savez-vous plus ?
Merci aux pros (!)
--
Léo
(http://www.cerber mail.com/?Nd39r1gp1C)
Poser une question
J'ai été confronté aux mêmes problèmes au point que j'en avais désactivé
flash dans les modules complémentaires de IE7. Et cela avait complètement
résomu mes Pb d'engloutissement de mes ressources processeur... ce qui fut
très très bénéfique à l'accelération de IE7 et à l'affichage des pages web.
Cependant, certains sites, sans flash perdent une partie de leur intérêt.
Tout dernièrement j'ai mis à jour le flash palyer. J'ai donc réactivé le
module dans IE7 et j'ai eu l'agréable surprise de constater que cette MàJ
était beaucoup moins gourmande en ressource processeur. A tel point
qu'aujourd'hui je navigue à nouveau avec le module activé dans IE7 et que la
vitesse du soft et la navigation reste confortable. Certaines pubs en flash
reste parfois un peu gourmandes, mais moins qu'avec la version précédente.
Ma version du flash player est : 9.0.45.0 (module Flash9c.ocx activé dans
IE7).
Tiens moi au courant.
Pat.
"Léo" <hurleven[at]laposte(dot)net> a écrit dans le message de news:
uHUCL$
Les stacks traces que montrent process explorer ne vous seront pas d'un
grand secours, une fois que vous avez isolé que le pb était bien lié à
Flash. Effectivement les fontions exposes dans les threads ne sont pas d'un
grand secours sans les fichiers symbols (appelé PDB). Mais la encore même
avec ces ficheirs symboles il serait interessant d'avoir accès au code
source des DLLs incriminées et la c'est à l'editeur de s'y pencher.
-Didier
"Léo" <hurleven[at]laposte(dot)net> wrote in message
news:uHUCL$
Merci pour ton commentaire ...
J'utilise aussi cette même version de Flash mais le problème est
toujours présent ...
Le problème apparaît dans un usage multi-onglets, donc de parallélisme
relativement intense (cours de bourse en temps-réel sous java, Flash dans
les pages) donc de contention.
Mais je ne suis pas persuadé qu'il s'agisse d'une attente active (boucle
sur un test). Ça ressemble plutôt à une attente qui dépend de l'arrivée de
données du réseau (mais je ne vois pas de connections suspectes ou étranges)
...
Je continue mes observations ...
Léo
"Patrick L."
Je sais bien que je ne suis pas en mesure de déboguer (ou simplement
comprendre ce qui se passe).
Mais ces traces, partiellement symbolisées permettent quand même de
constater que le problème n'est pas imputable à la machine virtuelle java
(une de mes premières intuitions) mais bien à Flash dans un contexte de
parallélisme relativement intense.
Je ne suis pas en mesure de transmettre le problème aux concepteurs de
Flash (ou je n'ai pas encore exploré cette possibilité) ...
Léo
"Didier Corvest [MS]" de news:
Je me demande si ces difficultés ne se situent pas dans le pilote
d'affichage nVidia ...ou dans nView de nVidia ...
Vous connaissez ? Ça vous rappelle des problèmes du même genre ?
Merci de nous en faire le cas échéant ...
Merci
"Léo" <hurleven[at]laposte(dot)net> a écrit dans le message de news:
uHUCL$