New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 717911 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Traces should expose number of tabs and tab vs process mapping

Project Member Reported by primiano@chromium.org, May 3 2017

Issue description

A recurring pattern when looking at traces is:
- some renderers have scary memory numbers (~1-2 GB per renderer)
- I start freaking out "how can website X take 1 GB"
- Then I realize that that process is actually hosting a mix of tabs, because we maxed out the number of renderers.

Example traces:
https://bugs.chromium.org/p/chromium/issues/detail?id=717636#c11 
https://bugs.chromium.org/p/chromium/issues/attachment?aid=276647

In essence, it is very hard to infer how many tabs are there in a trace (as opposite to how many renderer processes) and how they map to processes.

IMHO there are two fundamental data points missing:
1) I think that the trace metadata should have something a number_of_tabs (or number of frames?)
2) Would be nice if the tab title somehow reflected the number of tabs/frames hosted in that process. Right now I think that what happens is that titles are merged with a comma, but that makes very hard to read traces.




 
Cc: dskiba@chromium.org
We need a good place for such "context" values, a fake entry in MDP table perhaps? Right now we report uptime next to process name, which does the job, but is not very extensible.

For example event the URL reported next to renderer's name is not accurate in case there are several tabs? It would be nice to report URLs for all tabs.

Comment 2 by w...@chromium.org, May 3 2017

Ideally we'd include both the active WebContents in the process, and any
others which have affinity with that process - otherwise a process can be
bloated because something else was loaded into it, leaked, and was
subsequently unloaded.
Cc: nduca@chromium.org
Re #1: this is not memory-infra specific, is a more generic tracing flaw. Don't this this should be solved at a memory-infra level.

>  Right now we report uptime next to process name, 
uh? I thought we only report the PID.

I think we could start easy by making the Process track something like
[# Of WebContents associated] Merged Titles (PID)

and maybe have a tooltip that, when hovering the track, shows the titles of all WebContents, one per line.

+nduca WDYT?
Project Member

Comment 4 by sheriffbot@chromium.org, May 4 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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.

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

Sign in to add a comment