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

Issue 738524 link

Starred by 1 user
Status: Untriaged
Owner: ----
Cc:
█ ajwong@chromium.org
etienneb@chromium.org
ssid@chromium.org
█ dskiba@chromium.org
primiano@chromium.org
█ picksi@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug
Hotlist-MemoryInfra



Sign in to add a comment

chrome://tracing doesn't work for native heap profiling.

Project Member Reported by erikc...@chromium.org, Jun 30 2017 
I've been using native heap profiling for ~1 month. When used with my real profile [couple of windows, ~50-100 tabs total], a single memory dump is 100+MB [compressed], ~700MB uncompressed. Using TraceOnTap, it takes about 5 minutes to grab/compress a dump.

I've pretty much never been able to use chrome://tracing to grab or view these dumps. If we want to support native heap profiling in chrome://tracing, there are several things we need to fix [or is it even possible (?)].

  1) 5 second dump interval between dumps doesn't work. We need a single dump, and a way to tell if that single dump is finished.
  2) Ability to save a dump. My observation is that the maximum support save-size for chrome://tracing is ~50MB compressed. Anything that would have been larger causes an error.
  3) Ability to open a dump. My observation for the max size is ~25MB. Anything larger than that causes an import error.
  4) Is it possible to make dumps smaller? Or selectively dump for a subset of all processes?

All of this being said...I'm not sure chrome://tracing will ever be able to scale to fully support our current heap dumps. e.g. If a renderer has a max limit of ~1.5GB, I don't see how it can accommodate a JSON of ~700MB [or larger].

Comment 1 by erikc...@chromium.org, Jun 30 2017 

Example of a symbolized trace from native heap profiling w/ a real profile:

https://drive.google.com/a/google.com/file/d/0B6ho_7_ut5e1d3FBWmFKSm5vVDg/view?usp=sharing [124MB post compression]

Comment 2 by ssid@chromium.org, Jun 30 2017 

Some ideas:

Okay since we are facing trouble working with chrome://tracing, I think we should just stop using periodic dumping. How about requesting one global dump and wait till the user clicks Stop. This should solve at least the 1st problem.

Maybe we can make 3 categories: memory-infra-browser memory-infra-renderer and gpu. We only create heap dumps only for these processes on these categories.
We definitely need a better memory tracing UI than just start and stop tracing. But this would be a good short term usable tool.
This still would not solve the problem of 100 renderers creating heap dumps into trace. Maybe we should let browser make a decision on which processes's trace file should be added to trace file. Maybe the summary computation code can be used to sort the dumps by size of allocators and the top ones get into trace, assuming that we are only interested in the top ones. Again these should happen only on the memory-infra-renderers category.
►

Sign in to add a comment