Memory metric reporting values for "unknown_browser" |
|||
Issue descriptionIt's more evident on background pages in memory.top_10_mobile, but possibly occurs also elsewhere, the memory metric fails to identify the browser name (e.g. chrome or webview) and reports metrics for an "unknown_browser" instead. As an example the following build: https://ci.chromium.org/p/chrome/builders/luci.chrome.ci/android-go-perf/1960 Ran the background wikipedia and only found the correct browser name 2/5 times: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/after_http_en_m_wikipedia_org_wiki_Science_2018-12-09_09-27-34_52346.html (unknown) https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/after_http_en_m_wikipedia_org_wiki_Science_2018-12-09_09-32-02_31204.html (chrome) https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/after_http_en_m_wikipedia_org_wiki_Science_2018-12-09_09-36-19_32351.html (unknown) https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/after_http_en_m_wikipedia_org_wiki_Science_2018-12-09_09-40-44_76166.html (chrome) https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/after_http_en_m_wikipedia_org_wiki_Science_2018-12-09_09-45-06_87186.html (unknown) Since the metric we track, alert on, and run bisects on *has* the name of the browser on it, this is reducing the effectiveness of the benchmark and increasing noise in the metrics. As other symptoms, this graph shows the total number of background story runs which produced metrics under the correct names: https://v2spa-dot-chromeperf.appspot.com/#session=bc1158f43b527cd7db919e6612b1f1f7c8832dd3f43c49602db3d94c9f1b31d6 It used to be pretty consistent at 50 samples total, but started becoming very erratic somewhere in the range: http://test-results.appspot.com/revision_range?start=603917&end=604020 which does include the latest perfetto reland at r603931. Another symptom is "spotty" data on the legacy health dashboard, which purposefully omits any data points that do not include the expected 50 samples. https://chrome-health.googleplex.com/health-plan/android-chrome/memory/go-phone-1024/
,
Dec 11
eseckler: This sounds similar to the missing threadnames issue?
,
Dec 12
Looks similar, yeah. Though these traces seem to only be missing thread/process names from the browser and not the renderer. What's weird is that this wasn't addressed by crrev.com/c/1340325. Other graphs that were once flaky because of the missing thread names have returned to consistent results after that patch landed, e.g. [1]. If we somehow still end up dropping some metadata events, this should eventually be addressed by scraping of uncommitted buffers in the perfetto service, i.e. issue 907069 . [1] https://chromeperf.appspot.com/report?sid=00a1777d5d832fc2fdf96d65c1bd00d151512bf11148382b3cfe1589a647e931&start_rev=601532&end_rev=615788 |
|||
►
Sign in to add a comment |
|||
Comment 1 by perezju@chromium.org
, Dec 11139 KB
139 KB View Download