Issue metadata
Sign in to add a comment
|
High browser process CPU consumption and occasional hangs apparently due to memory instrumentation |
||||||||||||||||||||||||
Issue descriptionIn Issue 826913 browser hangs were reported that were caused by memory instrumentation. I'm continuing to see issues in recent Canarys. I have about 30 tabs open in one window and Calendar open in a second window. The browser gets more and more sluggish over a period of days, until it gets to the point where it's hanging with the pinwheel spinning for many seconds at a time. This often happens when using Command-Tab to switch tasks and come back to the browser. Switching tabs is often sluggish and I see UI delays of hundreds of milliseconds, if not more than a second, when performing interactive tasks like typing into Google Docs. This behavior has been present for about a month. Here's a symbolized sample gathered recently when this was happening. I see a lot of references to heap_profiling code which I suspect is adding significant overhead to all memory allocations. Can this be triaged in its current form? Are there other similar reports? What other information can I gather?
,
May 11 2018
Hm. The top culprits in the sample are all pointing at the heap profiler. Try going to about://flags and setting #memlog to "none by default". But looking at the post common posted tasks - your main thread and background thread are very busy doing something related to cookies + extensions.
,
May 14 2018
Currently #memlog is set to "Disabled" in my Canary's about:flags. Not sure whether that setting might have been changed since I gathered the above sample. If it's set to Disabled, does that definitely mean that the heap profiler should not be showing up? That way I can report whether something's broken in the handling of that flag.
,
May 14 2018
#memlog - Disabled is the default, but you're being affected by a Finch experiment. I'm not aware of a mechanism to propagate finch experiments back into chrome://flags.
,
May 15 2018
Ah, I see. OK, have set #memlog to "none by default" and will report back here if I continue to see these browser hangs. What's the name of this experiment and which release channels are affected by it?
,
May 15 2018
The experiment name is OOPHeapProfiling*. It affects 5% of Canary/Dev. 50% of Canary/Dev for Googlers. It's known to have a visible effect [~30% in the higher percentiles] on certain malloc-heavy code paths in the browser [e.g. Omnixbox]. Given this report and a couple of others, I intend to dial down the sampling parameters to reduce overhead by 10x [we think this shouldn't affect accuracy of the data being reported].
,
May 16 2018
,
May 17 2018
I've reduced the sampling rate on desktop to 100k, which should reduce overhead by ~10X. Please let me know if you still see issues on latest canary. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by kbr@chromium.org
, May 11 20181.2 MB
1.2 MB View Download