Public bug reported:
At a high level, in certain instances we’re experiencing sustained
abnormally high (100%) CPU utilization from Firefox. This utilization
is competing with other critical application processes on the systems,
starving them of resources, causing issues in the application
processing. This happens, at times, when the browser should be idle,
even.
We have not isolated this issue to be a bug with firefox itself or an issue
with the webpage content being provided to the browser. Regardless, here are
the symptoms:
* CPU usage is extremely high for the FireFox process (>100% on average vs
<10% average for healthy stations) even while the screen is sitting idle (no
animations, user interactions, etc.)
* We have isolated the thread within FireFox causing the most CPU usage to
the Renderer thread with the SwComposite threads also consuming abnormally high
CPU.
* In the FireFox Task and Process Managers, we have validated there is no
single tab or window consuming abnormally high CPU, just the FireFox master
process.
* Additionally, we have confirmed that the FireFox browser history (taken
from the places.sqlite file) does not have any webpages being loaded during the
times when CPU consumption experiences a step function change up or down.
* We also have linux perf logs for the FireFox process on healthy stations
and impacted stations while sitting idle on the login screen, which can provide
some stack traces for the Renderer and other threads which may be more useful
to someone with FireFox expertise.
* The biggest difference is that the impacted workcells have the Renderer
and Compositor 'tracks' very active while the healthy workcells see no usage of
these tracks at all.
* These 2 tracks also have supporting tracks such as SwComposite and
WRRendererBackend#X. There were 2 of each of these, which may indicate the
issue is happening across both FireFox windows. For reference, the stations
always have 2 windows open: one for the screen UI and one for the projector on
the pod face.
* (Using the term 'track' here as defined by the open source FireFox
profiler: https://profiler.firefox.com/. Basically a thread within the FireFox
main process)
* There are many memory copy and SW interrupt calls being made in these
tracks.
* This validates that FireFox is contributing to increased software
interrupt load
* Additionally, we found an interesting pair of calls occurring periodically
in the Renderer track. We have not deep dived these yet, but on the off chance
it matters, we're including it in this report:
* viaduct_log_error - every 50 - 500ms
* wgpu_render_pass_end_pipeline_statistics_query - every 50 - 1000ms
** Affects: firefox (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/2048792
Title:
Firefox utilizins 100% of station CPU
Status in firefox package in Ubuntu:
New
Bug description:
At a high level, in certain instances we’re experiencing sustained
abnormally high (100%) CPU utilization from Firefox. This utilization
is competing with other critical application processes on the systems,
starving them of resources, causing issues in the application
processing. This happens, at times, when the browser should be idle,
even.
We have not isolated this issue to be a bug with firefox itself or an issue
with the webpage content being provided to the browser. Regardless, here are
the symptoms:
* CPU usage is extremely high for the FireFox process (>100% on average
vs <10% average for healthy stations) even while the screen is sitting idle (no
animations, user interactions, etc.)
* We have isolated the thread within FireFox causing the most CPU usage to
the Renderer thread with the SwComposite threads also consuming abnormally high
CPU.
* In the FireFox Task and Process Managers, we have validated there is no
single tab or window consuming abnormally high CPU, just the FireFox master
process.
* Additionally, we have confirmed that the FireFox browser history (taken
from the places.sqlite file) does not have any webpages being loaded during the
times when CPU consumption experiences a step function change up or down.
* We also have linux perf logs for the FireFox process on healthy stations
and impacted stations while sitting idle on the login screen, which can provide
some stack traces for the Renderer and other threads which may be more useful
to someone with FireFox expertise.
* The biggest difference is that the impacted workcells have the Renderer
and Compositor 'tracks' very active while the healthy workcells see no usage of
these tracks at all.
* These 2 tracks also have supporting tracks such as SwComposite and
WRRendererBackend#X. There were 2 of each of these, which may indicate the
issue is happening across both FireFox windows. For reference, the stations
always have 2 windows open: one for the screen UI and one for the projector on
the pod face.
* (Using the term 'track' here as defined by the open source FireFox
profiler: https://profiler.firefox.com/. Basically a thread within the FireFox
main process)
* There are many memory copy and SW interrupt calls being made in these
tracks.
* This validates that FireFox is contributing to increased software
interrupt load
* Additionally, we found an interesting pair of calls occurring
periodically in the Renderer track. We have not deep dived these yet, but on
the off chance it matters, we're including it in this report:
* viaduct_log_error - every 50 - 500ms
* wgpu_render_pass_end_pipeline_statistics_query - every 50 - 1000ms
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2048792/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
