1922234 - High shared memory usage on lagosjumpradio.com

Status: NEW

(Core :: Performance, defect, P3)

Description

[Calin Tanase (OOO until 22nd of Nov)]

The report was received on github via webcompat, personally we were not able to reproduce this issue. Moved it here for further investigations.

From github: https://github.com/webcompat/web-bugs/issues/141867.

<!-- @browser: Firefox ESR 115.15.0 -->
<!-- @ua_header: Mozilla/5.0 (Android 14; Mobile; rv:130.0) Gecko/130.0 Firefox/130.0 -->
<!-- @reported_with: unknown -->

URL: https://lagosjumpradio.com

Browser / Version: Firefox ESR 115.15.0
Operating System: Windows 10
Tested Another Browser: Yes Chrome

Problem type: Something else
Description: Firefox with one tab (Lagos JumpRadio) uses 500MB
Steps to Reproduce:
Using firefox with only one tab (https://lagosjumpradio.com/?proradio-popup=1)
and in truvleshoot mode uses 580MB
<details>
<summary>View the screenshot</summary>
<img alt="Screenshot" src="https://webcompat.com/uploads/2024/9/50d9b10b-16c6-4a75-8722-20cb3874b492.jpg">
</details>

<details>
<summary>Browser Configuration</summary>
<ul>
<li>None</li>
</ul>
</details>

From webcompat.com with ❤️

Change performed by the Move to Bugzilla add-on.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 2

[Damp Canary]

Attachment: Firefox-2024-10-02-1729-profilejson.gz

Comment 3

[Damp Canary]

Hi Calin Tanase,

Thank You for directing me here.
I recoreded this profiler log

Comment 4

[Markus Stange [:mstange]]

Could you also attach a memory report from about:memory?

Comment 5

[Damp Canary]

Attachment: LagosJumpRadio_memory-reportjson.gz

Hello Marcus Stange,
sorry for late reply, PC on which I noticed this is work station so I needed to return to office.
This is memory log from about:memory after firefox was working over night.

Comment 6

[Frank Doty [:fdoty]]

Removing perf impact flag and adding to memory investigation meta bu - please continue to provide additional details to help us remedy any possible issues

Comment 7

[Damp Canary]

Hi,

Of course, any information I can gather.
Only thing is this happens on work PC so I may not have always acess to it, so sometimes I might need some time to gather/reply.
Thanks again for support.

Comment 8

[Markus Stange [:mstange]]

Andrew, can you help me read this report? See https://github.com/webcompat/web-bugs/issues/141867 for the history - with just one tab open, the reporter sees a higher value on about:processes for the parent process than various other people.
In the attached memory report, I see 772.31 MB of resident in the parent process, and 150.64 MB of explicit. I also see 402.87 MB of shmem-mapped, would that explain the difference? Do you notice anything suspicious in the report?

Comment 9

[Andrew McCreight [:mccr8]]

Explicit is memory allocated by jemalloc (or the GC), whereas resident will include all uses, and shmem isn't allocated by jemalloc, so that would account for a lot of it, certainly. 400 does seem like a lot of shmem when explicit is so low. Honestly, that explicit value is surprisingly low.

The about:memory report looks reasonable to me. The screenshots from the webcompat issue do show what look like high GPU process values, so maybe there's something off there? Graphics is a major user of shmem. Though they are seeing what look like high values to me across all sites so I'm not sure.

Comment 10

[Damp Canary]

Hi,

Update for ESR version (v115->v130) just popped up, should I update and re-run tests for same webpages?
Maybe there will be changes in memory consumptions and it helps narrowing the cause.

Would leaving radio play troughthout the weekend in both ESR and nightly and then dumping memory (and/or processes) be helpful?