High gfx/webrender/swgl memory
Categories
(Core :: Graphics: WebRender, enhancement)
Tracking
()
People
(Reporter: szybalski, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Steps to reproduce:
User Story:
Top of the line Hardware: Debian Stable, 65GB of ram, Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz, NVMe 256GB
Work type: General software development research, applying for jobs.
Firefox Status: ~5-15 window browsers, 10-20 tabs each.
User doesn't want to be limited by software, and will not accept typical FAQ resolutions like close tabs,etc. The user rather upgrade hardware, but at this point the hardware is well beyond what is needed.
Actual results:
Problem:
Firefox Memory and cpu manager is not efficiently processing, and controlling websites resulting in system over utilization to a point of firefox freezing. A typical usage is after few days or 2 weeks is:
VIRT: 11.0gb
RES: 3.4GB
CPU: 45.2%
%MEM: 5.4
Load average: 4.76
Expected results:
Solution:
This is a 2 part ticket.
The first part that we want to address here is a long term plan for memory, cpu, and resource management of tabs.
The second is implementation of said plan.
With outcome being that firefox is performing "snappy" and can easily hold up to 100 tabs across windows without 'load on system' being hired then 1.2.
Ideas on achieving this could take a form of the following sub-tickets:
- Currently there is no way to list all tabs and window and current memory and cpu utilization (virtual and REST), file descriptors, each tab is using. If we were able to achieve something similar to "top" or "ps -a" command in linux for firefox, we could start identifying memory and cpu usage per tab, and dig into individual javascript (I assume) related standard activities that balloon the system. From there we can identify a pattern of I'm sure <8 that cause 80% of the utilization. (80/20 rule, we want to tackle 20% of problems that cause 80% of utilization; if criteria not matched, move to different ticket)
- Reproduce: One can start seeing this when you open 100 tabs of linkedin for example. (Click on your favorite organization "Mozilla", click people , then narrow down to "skilled at JavaScript", and open all 192 of them.(This is a quick real world example of how you can hog down the system.) Click every few sec, let tabs load, the spend some time looking at maybe 20-40 of them this morning, just to get familiar what they are about. By Afternoon system is unbearable. You can take this example but replace the task with (gmail, social media, seo research, ai implementation research, reach research,etc)
- Why this ticket? I wish I could tell you that chromium engine has this figured out, but they don't. They also have the same problem, so you will be at the frontier of cutting edge when you work on this ticket. You will be the hero that saved 15min each day * 260 working days * millions of people time. They get to improve the world with your ingenuity!
Admin work:
The following 192 tickets related to memory utilization should be then categorized when capability of usage breakdown is developed, and each is requested to provide more information. This is just the beginning of 13 million page results on google related to "firefox memory usage problem", 160 stack overflow related to same topic,etc
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Reporter | ||
Comment 2•2 years ago
|
||
Reporter | ||
Comment 3•2 years ago
|
||
About:process: CPU 60% constant. Looks like the idle cpu usage is always that %, not matter what. Not I'm not doing anything on it, this is just tabs, I left Saturday.
youtube (paused, not playing), fluctuates at 17% to 50% but mostly at 17%
2 tabs
(subframe 6)
Thanks Harveer Singh for pointing about about:memory about:processes
Thanks
Lucas
Comment 4•2 years ago
|
||
(In reply to Lukasz Szybalski from comment #3)
About:process: CPU 60% constant. Looks like the idle cpu usage is always that %, not matter what. Not I'm not doing anything on it, this is just tabs, I left Saturday.
youtube (paused, not playing), fluctuates at 17% to 50% but mostly at 17%
2 tabs
(subframe 6)
It would be useful if you could share a profile of what's happening. Go to https://profiler.firefox.com/, enable the profiler menu button, then start recording, and after some time capture the profile, then upload and share it.
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Looks like you are on the esr branch. A profile would be a lot more helpful if you capture it from a Nightly version of Firefox downloaded from https://nightly.mozilla.org/.
Comment 5•2 years ago
|
||
Some notable parts of the memory report:
2,535.24 MB (100.0%) -- explicit
├──1,852.61 MB (73.07%) -- gfx
│ ├──1,815.40 MB (71.61%) -- webrender
│ │ ├──1,732.95 MB (68.35%) ── swgl
1,858.54 MB (100.0%) -- gfx
└──1,858.54 MB (100.0%) -- webrender
├──1,680.66 MB (90.43%) -- textures
│ ├────596.75 MB (32.11%) ── render-targets
│ ├────404.29 MB (21.75%) ── render-texture-hosts
│ ├────308.50 MB (16.60%) -- texture-cache
2,295.04 MB ── heap-allocated
2,978.00 MB ── heap-mapped
2,319.09 MB ── resident
2,636.45 MB ── resident-peak
1,849.66 MB ── resident-unique
Comment 6•2 years ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:gw, since the bug doesn't have a severity set, could you please set the severity or close the bug?
For more information, please visit BugBot documentation.
Comment 7•2 years ago
|
||
Closing due to needinfo inactivity. Feel free to reopen if still occurring.
Description
•