high mem usage
Categories
(Core :: Graphics: ImageLib, defect, P3)
Tracking
()
Performance Impact | low |
People
(Reporter: jronpaul, Unassigned)
Details
(Keywords: perf:resource-use, Whiteboard: [memshrink])
Attachments
(5 files, 1 obsolete file)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0
Steps to reproduce:
Name Firefox
Version 95.0.1
Build ID 20211215221728
Distribution ID min
open firefox.. i have a about 100 tabs open
and it uses all my 8G of memory and starts to use swap
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•3 years ago
|
||
pid 1380 has some large-ish numbers for WR/Imagelib.
@jronpaul : are you able to tell which that pid 1380 corresponds to which webpage?
Also, please attach your about:support
damn... its on my wife's computer and she restarted firefox. i can wait until it starts using memory again and send another report.
ive attached the about:support
here is a memory report from the latest firefox..
the memory usage is steadily increasing.
here is a memory report from the latest firefox..
the memory usage is steadily increasing.
ow the laptop is maxing out memory.
total used free shared buff/cache available
Mem: 7.6Gi 6.3Gi 221Mi 656Mi 1.0Gi 330Mi
Swap: 2.0Gi 1.9Gi 114Mi
attached a new memory report...
here is what happens when i close firefox and open it again..
you can see how high the mem usage was..
and now it will steadily increase past 100% utilization again
Updated•3 years ago
|
Comment 9•3 years ago
|
||
When you attached about:support
, was it before or after the issue was seen? I'd be curious as to its contents after the memory is growing. While there aren't an extraordinary number of images mapped into the parent process (it is often high), I am suspicious of just how many of those images are missing a creator ref. That would imply we only want to keep them alive until the next frame is processed, but surely we shouldn't see that many.
I don't think we handle early returns well when we create ScheduleSharedSurfaceRelease:
https://searchfox.org/mozilla-central/rev/fac07284a9a996ddf968ea53adaf25c2a8b7c520/gfx/layers/wr/WebRenderBridgeParent.cpp#482
If there are missing fonts or something, e.g.:
https://searchfox.org/mozilla-central/rev/fac07284a9a996ddf968ea53adaf25c2a8b7c520/gfx/layers/wr/WebRenderBridgeParent.cpp#626
Combined with animated image updates, we might leak the images too. However there should be entries in the critical log if that is the case, and that should show up in about:support.
Reporter | ||
Comment 10•3 years ago
|
||
(In reply to Andrew Osmond [:aosmond] (he/him) from comment #9)
When you attached
about:support
, was it before or after the issue was seen? I'd be curious as to its contents after the memory is growing. While there aren't an extraordinary number of images mapped into the parent process (it is often high), I am suspicious of just how many of those images are missing a creator ref. That would imply we only want to keep them alive until the next frame is processed, but surely we shouldn't see that many.I don't think we handle early returns well when we create ScheduleSharedSurfaceRelease:
https://searchfox.org/mozilla-central/rev/fac07284a9a996ddf968ea53adaf25c2a8b7c520/gfx/layers/wr/WebRenderBridgeParent.cpp#482If there are missing fonts or something, e.g.:
https://searchfox.org/mozilla-central/rev/fac07284a9a996ddf968ea53adaf25c2a8b7c520/gfx/layers/wr/WebRenderBridgeParent.cpp#626Combined with animated image updates, we might leak the images too. However there should be entries in the critical log if that is the case, and that should show up in about:support.
ok.
attached a new about:support.
Reporter | ||
Comment 12•3 years ago
|
||
(In reply to Andrew Osmond [:aosmond] (he/him) from comment #9)
When you attached
about:support
, was it before or after the issue was seen? I'd be curious as to its contents after the memory is growing. While there aren't an extraordinary number of images mapped into the parent process (it is often high), I am suspicious of just how many of those images are missing a creator ref. That would imply we only want to keep them alive until the next frame is processed, but surely we shouldn't see that many.I don't think we handle early returns well when we create ScheduleSharedSurfaceRelease:
https://searchfox.org/mozilla-central/rev/fac07284a9a996ddf968ea53adaf25c2a8b7c520/gfx/layers/wr/WebRenderBridgeParent.cpp#482If there are missing fonts or something, e.g.:
https://searchfox.org/mozilla-central/rev/fac07284a9a996ddf968ea53adaf25c2a8b7c520/gfx/layers/wr/WebRenderBridgeParent.cpp#626Combined with animated image updates, we might leak the images too. However there should be entries in the critical log if that is the case, and that should show up in about:support.
ohh.. sorry, i didnt answer your question.. the 1st about:support that was attached was when it was in the middle of high mem usage. i believe.
Comment 13•3 years ago
|
||
Interesting. It could be a different problem then..... perhaps I can augment the memory reports in a better way.
Reporter | ||
Comment 14•3 years ago
|
||
(In reply to Andrew Osmond [:aosmond] (he/him) from comment #13)
Interesting. It could be a different problem then..... perhaps I can augment the memory reports in a better way.
sorry, im not sure what you mean exactly.. but let me know if there is anything else I can supply.
Comment 15•3 years ago
|
||
Hey Andrew, just pinging you to answer above questions and keep the bug moving :-) Thanks!
Reporter | ||
Comment 16•3 years ago
|
||
any updates?
thanks
Updated•3 years ago
|
Comment 17•3 years ago
|
||
There does not appear to be anything in the critical log in about:support. I'm not sure if I have much to go on by here. I did land bug 1749526 which should handle complete transactions, and avoid memory leaks for animated images in those events. Does the latest nightly help at all?
Comment 18•3 years ago
|
||
I also don't see much evidence in the about:memory dumps that the problem is related to images / surfaces.
Summing up the "resident" sizes of all processes in each report, I do get something around 8GB, which matches the reporter's description.
attachment 9257123 [details]: 9271.84 MB
552.23 + 727.46 + 681.12 + 514.61 + 491.87 + 420.78 + 369.68 + 276.82 + 264.38 + 252.11 + 235.52 + 226.93 + 208.17 + 191.80 + 183.93 + 156.24 + 141.29 + 139.87 + 133.48 + 130.92 + 130.56 + 129.56 + 122.18 + 120.83 + 119.60 + 118.91 + 118.16 + 114.83 + 111.57 + 108.25 + 107.77 + 105.59 + 104.39 + 102.76 + 101.23 + 98.68 + 97.89 + 94.80 + 94.54 + 92.24 + 89.70 + 84.21 + 83.22 + 82.75 + 80.52 + 78.94 + 71.78 + 71.77 + 69.86 + 33.68 + 31.86
attachment 9256878 [details]: 7943.07 MB
692.18 + 360.95 + 347.82 + 329.25 + 284.12 + 235.82 + 220.04 + 213.34 + 209.39 + 203.71 + 193.20 + 179.21 + 170.69 + 151.66 + 144.94 + 138.65 + 137.81 + 125.44 + 121.74 + 109.00 + 107.16 + 100.69 + 100.21 + 93.92 + 90.79 + 89.54 + 88.01 + 86.86 + 85.72 + 84.37 + 82.62 + 79.86 + 78.14 + 75.91 + 75.77 + 73.95 + 72.61 + 71.68 + 70.95 + 70.73 + 70.43 + 70.20 + 66.81 + 65.78 + 65.40 + 64.43 + 62.46 + 62.13 + 59.56 + 59.31 + 57.59 + 55.46 + 53.93 + 52.30 + 52.20 + 51.37 + 51.31 + 50.36 + 49.18 + 48.84 + 48.17 + 46.79 + 45.53 + 41.32 + 40.27 + 37.21 + 36.61 + 35.66 + 34.86 + 34.59 + 34.55 + 32.89 + 30.86 + 14.32 + 11.94
attachment 9257000 [details]: 8271.72 MB
820.03 + 596.90 + 555.11 + 355.20 + 329.19 + 311.38 + 302.23 + 295.17 + 292.30 + 265.19 + 263.52 + 245.45 + 215.48 + 196.41 + 188.64 + 165.61 + 162.02 + 150.37 + 147.68 + 144.16 + 143.84 + 136.06 + 134.82 + 130.29 + 129.40 + 126.58 + 123.29 + 120.86 + 114.09 + 112.72 + 112.52 + 108.63 + 102.97 + 96.93 + 95.32 + 92.84 + 89.11 + 72.61 + 72.44 + 72.13 + 42.12 + 40.11
But the memory seems to be mostly used by web pages / JS memory. It looks like lots of tabs are opened or loaded and never closed. Restarting helps because tabs are loaded lazily.
Or maybe something leaks the tab contents? Or maybe there's a leak in an add-on?
Unloading background tabs when memory becomes tight would help here.
Updated•3 years ago
|
Reporter | ||
Comment 19•3 years ago
|
||
definitely have a lot of tabs open and most just sit there..
she is leaving them up to remind her to look at them..
i have also told her that they need to be saved and closed..
that said, i thought it seemed like using all the memory was a bit much..
i loaded her .mozilla file onto a server I have with 62G of memory and it used 18G when i launched ff
and loaded all the tabs.
Comment 20•2 years ago
|
||
The Performance Priority Calculator has determined this bug's performance priority to be P3. If you'd like to request re-triage, you can reset the Performance flag to "?" or needinfo the triage sheriff.
[x] Causes severe resource usage
Updated•2 years ago
|
Description
•