When you go to More Tools->Task Manager in Chrome, what process does it say is consuming all that CPU time

scastelli7@: Please respond to the question in comment #2 so that we can further assist you.

HI Jkarlin, I've asked to my customer some screenshot in order to get the more information I can.
By now I have only one screenshot ( attached ) where Chrome uses 14% of CPU after a translation.

Deleted: b1.jpg 34.4 KB

	b1.jpg 34.4 KB View Download

Tentatively attaching the blink label - that's the renderer process, and the network stack doesn't do anything there, though more goes on in the renderer process than running Blink.

Attach you could find some other screenshot, the first one is with google sheet and the second one shows the impact of it on the hypervisor.

Deleted: gs.jpg 274 KB

	gs.jpg 274 KB View Download

Deleted: pm.jpg 399 KB

	pm.jpg 399 KB View Download

Thank you for providing more feedback. Adding requester "mmenke@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

Could you create a trace as per instructions in https://www.chromium.org/developers/how-tos/submitting-a-performance-bug and attach it to this bug? Thank you!

Here is a trace from google sheet
Thanks

Deleted: trace_Sheets-Prototipi.json.gz 1.2 MB

trace_Sheets-Prototipi.json.gz 1.2 MB Download

Hmm, some activity on the IO thread... putting this in networking for now

Unassigning from myself

 cbiesinger:  How are you getting the IO Thread from that? Trace claims it only spent 150ms of CPU time.  CrBrowserMain (UI thread?) spent more like 4 seconds, looks like.  

mmenke: I focused on the events *after* the main load of the page. But actually maybe that was a mistake.

scastelli7: To clarify, are you concerned about CPU usage while the page is loading, or while it's "idle" afterwards?

That 150ms of CPU time on the IO thread is for the entire duration of the trace, before, after, and during the page being loaded.  Zoom out, highlight everything on the Chrome_IOThread, look at the total time.  Am I missing something?

I think you're right, and I just failed to read the trace. I'll leave this to someone else for triage.

The cpu stay High after the page is loaded

scastelli7:  Could you please provide another trace?  This time, load the page first.  Then start tracing and leave the browser running a minute or two before stopping the trace.  That should hopefully give us a stronger signal of what's going on.

Just to be clear, only start the trace after the page has finished loading, so we don't capture the page loading at all.

Here you are.
thanks

Deleted: trace_ProtoclloAttivitCOMM.json.gz 1.2 MB

trace_ProtoclloAttivitCOMM.json.gz 1.2 MB Download

Other 2 example

Deleted: trace_AttiCOMM2.json.gz 2.5 MB

trace_AttiCOMM2.json.gz 2.5 MB Download

Deleted: trace_SchedaAttComm.json.gz 2.7 MB

trace_SchedaAttComm.json.gz 2.7 MB Download

In the first trace (trace_ProtoclloAttivitCOMM):

IO Thread: 182 ms
UI Thread: 383 ms
Renderer main thread: 1,891 ms (Mostly V8.Execute and ResourceDispatcher:OnReceivedData)
Dedicated worker thread: 1,5591 ms (Mostly V8.GCIncrementalMarking)

Second trace (trace_AttiCOMM2) again shows most of the CPU time spend in the renderer, but it mostly shows time spent painting.

Third trace (trace_SchedaAttComm) shows time spent running V8 and painting.

Do you have any extensions installed?  Suggest you try disabling them, if so.

No extension installed

This is not a paint bug, it's something else.

How could we proceed to investigate deeper?

Long shot: is it possible that incremental marking gets confused on a shared environment like Citrix?

Tagging with current Dev milestone for tracking purpose.

is there any further test that i can make in order to debug this issue? As business we works whit Citrix every day and we deploy many VDI in different scenarios, only Chrome is so aggressive with the CPU and we could not understand why...

I don't see how Citrix (or any other virtualization environment) would have an influence on incremental marking.

I can see that incremental marking is running on a dedicated worker thread. So marking is probably not able to keep up with the allocation rate. I am only guessing here because we don't have a workload.

Any chance to try that on a current Dev release? Black allocation (just landed recently) should help with this behavior.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been moved once and is lower than Pri-1. Removing the milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Closing this issue because it is not actionable.