1347042 - MEMORY_IMAGES_CONTENT_USED_UNCOMPRESSED telemetry is unreasonably small

Status: RESOLVED INVALID

(Toolkit :: Telemetry, enhancement)

Description

[Timothy Nikkel (:tnikkel)]

The median value is always 0

https://telemetry.mozilla.org/new-pipeline/evo.html#!aggregates=median&cumulative=0&end_date=2017-03-13&keys=!__none__!__none__&max_channel_version=nightly%252F54&measure=MEMORY_IMAGES_CONTENT_USED_UNCOMPRESSED&min_channel_version=nightly%252F51&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-01-26&trim=1&use_submission_date=0

To get more detail we can look at this chart

https://codepen.io/anon/pen/jBwvow

It shows us that 63% of telemetry pings have < 1 MB reported for this value.

Most likely this is because this value only includes content images (as opposed to chrome images) and the parent process when e10s is enabled usually has a very small number of content images. For example after startup my local build had ~4000 bytes in the parent process.

We could sum the value over all processes and report one number but njn said there can be problems with that taking too long waiting for sync msgs cross process (ie bug 1340134 is currently a problem like that).

So I propose that we just ignore the value in the parent process when e10s is enabled. If that value in the parent process becomes large there is still about:memory to see that like any other memory report. This should be a quick way to make this telemetry probe actually provide usable information again.

Comment 1

[Timothy Nikkel (:tnikkel)]

Attachment: patch

Comment 2

[Georg Fritzsche [:gfritzsche]]

(In reply to Timothy Nikkel (:tnikkel) from comment #0)
> Most likely this is because this value only includes content images (as
> opposed to chrome images) and the parent process when e10s is enabled
> usually has a very small number of content images. For example after startup
> my local build had ~4000 bytes in the parent process.
> 
> We could sum the value over all processes and report one number but njn said
> there can be problems with that taking too long waiting for sync msgs cross
> process (ie bug 1340134 is currently a problem like that).
> 
> So I propose that we just ignore the value in the parent process when e10s
> is enabled. If that value in the parent process becomes large there is still
> about:memory to see that like any other memory report. This should be a
> quick way to make this telemetry probe actually provide usable information
> again.

Histograms from content and parent processes are tracked separately, you can switch to just looking at those: https://mzl.la/2ms463T

Does that solve your problem?

Comment 3

[Timothy Nikkel (:tnikkel)]

(In reply to Georg Fritzsche [:gfritzsche] [at workweek] from comment #2)
> (In reply to Timothy Nikkel (:tnikkel) from comment #0)
> > Most likely this is because this value only includes content images (as
> > opposed to chrome images) and the parent process when e10s is enabled
> > usually has a very small number of content images. For example after startup
> > my local build had ~4000 bytes in the parent process.
> > 
> > We could sum the value over all processes and report one number but njn said
> > there can be problems with that taking too long waiting for sync msgs cross
> > process (ie bug 1340134 is currently a problem like that).
> > 
> > So I propose that we just ignore the value in the parent process when e10s
> > is enabled. If that value in the parent process becomes large there is still
> > about:memory to see that like any other memory report. This should be a
> > quick way to make this telemetry probe actually provide usable information
> > again.
> 
> Histograms from content and parent processes are tracked separately, you can
> switch to just looking at those: https://mzl.la/2ms463T
> 
> Does that solve your problem?

Yeah, that works. We can also filter on the e10s setting. The values are still suspiciously low, but at least they are not (usually) 0. So we probably still need to look into that.

Comment 4

[Timothy Nikkel (:tnikkel)]

The evolution charts show up fine, but if I use the dashboard generator and choose either no e10s or child process only then I get "No data to graph".

Comment 5

[Georg Fritzsche [:gfritzsche]]

Comment on attachment 8846980 [details] [diff] [review]
patch

Review of attachment 8846980 [details] [diff] [review]:
-----------------------------------------------------------------

I don't think this is needed.
It should work already, we should figure out where exactly the problem is you have.

Comment 6

[Georg Fritzsche [:gfritzsche]]

I can see data at https://mzl.la/2n7zUhM, so maybe this is a problem with the generator or the used paramaters?
:frank is the person to ask for this data, others in #telemetry can probably help too.

Comment 7

[Georg Fritzsche [:gfritzsche]]

Did you solve this?

Comment 8

[Timothy Nikkel (:tnikkel)]

Yes, thanks for your help.