1514723 - high memory usage when importing a large amount of files on Google Photos

Status: RESOLVED INCOMPLETE

(Core :: DOM: Workers, defect, P3)

Description

[mathieu.tarral]

Attachment: process_list.png

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

import a large amount of photo and high quality videos on Google Photos (~400, ~6MB)

Tested with Firefox 63.0.3 (64 bits), on Fedora


Actual results:

Firefox consumes a lot of memory, until it fills the RAM and the swap, leading to a total system freeze


Expected results:

Firefox should have better handled it's memory consumption

Comment 1

[mathieu.tarral]

Attachment: system_resources_monitor.png

View of the system monitor

Comment 2

[Kanchan Kumari QA]

Hello Mathieu, could you please provide memory report (https://developer.mozilla.org/en-US/docs/Mozilla/Performance/about:memory) when you encounter this issue? This will help dev to look into the root cause of the issue. Thanks!

Comment 3

[mathieu.tarral]

I tried to reupload the same set of photos but I couldn't trigger the bug.
Also my connection change from last time I tried, I move to a different location, now it's the upload speed is very slow.

I will try again with the original high speed connection I had, maybe this will be enough.

Thanks.

Comment 4

[mathieu.tarral]

Attachment: memory-report.json.gz

Memory report when the Web process was using +3GB of RAM, when uploading a big set of high quality photos/videos on Google Photos.

Comment 5

[mathieu.tarral]

I uploaded the memory report as you asked me to, hope it will help the investigation !

Comment 6

[Kanchan Kumari QA]

Hello Eric, can you please look into the memory report? Thanks!

Comment 7

[Eric Rahm [:erahm]]

This is all in workers and images which makes sense when importing a large amount of photo and high quality videos on Google Photos. It's possible we shouldn't be keeping all this data around, lets send this over to graphics for now.

4,566.57 MB (100.0%) -- explicit
├──3,011.13 MB (65.94%) -- workers
│  ├──3,005.54 MB (65.82%) -- workers(google.com)
│  │  ├────654.58 MB (14.33%) -- worker(/_/scs/social-static/_/js/k=boq.PhotosCreationwebworker.fr.n25Gni89u9o.O/rt=j/d=1/rs=AGLTcCMIOGPlM_lRo3iYDUhT_ZharK_D6w/m=cwm, 0x7fceca90c800)
│  │  │    ├──652.07 MB (14.28%) -- zone(0x7fcee29bf000)
│  │  │    │  ├──651.09 MB (14.26%) -- realm(web-worker)
│  │  │    │  │  ├──650.48 MB (14.24%) -- classes
│  │  │    │  │  │  ├──648.95 MB (14.21%) -- class(ArrayBuffer)/objects
│  │  │    │  │  │  │  ├──648.91 MB (14.21%) ── malloc-heap/elements/normal
│  │  │    │  │  │  │  └────0.04 MB (00.00%) ── gc-heap
│  │  │    │  │  │  └────1.53 MB (00.03%) ++ (8 tiny)
│  │  │    │  │  └────0.61 MB (00.01%) ++ (7 tiny)
│  │  │    │  └────0.98 MB (00.02%) ++ (13 tiny)
│  │  │    └────2.51 MB (00.05%) ++ (3 tiny)
│  │  ├────652.48 MB (14.29%) ++ worker(/_/scs/social-static/_/js/k=boq.PhotosCreationwebworker.fr.n25Gni89u9o.O/rt=j/d=1/rs=AGLTcCMIOGPlM_lRo3iYDUhT_ZharK_D6w/m=cwm, 0x7fcecabfb000)
│  │  ├────652.24 MB (14.28%) ++ worker(/_/scs/social-static/_/js/k=boq.PhotosCreationwebworker.fr.n25Gni89u9o.O/rt=j/d=1/rs=AGLTcCMIOGPlM_lRo3iYDUhT_ZharK_D6w/m=cwm, 0x7fceca7dd000)
│  │  ├────650.93 MB (14.25%) ++ worker(/_/scs/social-static/_/js/k=boq.PhotosCreationwebworker.fr.n25Gni89u9o.O/rt=j/d=1/rs=AGLTcCMIOGPlM_lRo3iYDUhT_ZharK_D6w/m=cwm, 0x7fcec6be6000)
│  │  └────395.31 MB (08.66%) ++ worker(/_/scs/social-static/_/js/k=boq.PhotosCreationwebworker.fr.n25Gni89u9o.O/rt=j/d=1/rs=AGLTcCMIOGPlM_lRo3iYDUhT_ZharK_D6w/m=cwm, 0x7fcecabe8000)
│  └──────5.60 MB (00.12%) ++ (2 tiny)
├──1,220.48 MB (26.73%) -- images
│  ├──1,220.42 MB (26.73%) -- content
│  │  ├──1,220.33 MB (26.72%) -- raster/used
│  │  │  ├────138.19 MB (03.03%) ++ (54 tiny)
│  │  │  ├─────89.29 MB (01.96%) -- image(5472x3648, blob:https://photos.google.com/2891db9a-74a1-4177-b362-88deaeb56074)
│  │  │  │     ├──76.20 MB (01.67%) -- unlocked
│  │  │  │     │  ├──76.15 MB (01.67%) ── surface(5472x3648)/decoded-heap
│  │  │  │     │  └───0.05 MB (00.00%) ── surface(144x96)/decoded-heap
│  │  │  │     └──13.09 MB (00.29%) ── source
│  │  │  ├─────85.31 MB (01.87%) ++ image(5472x3648, blob:https://photos.google.com/da599cf9-729f-4c6a-916b-2a65c2bb6e1b)
│  │  │  ├─────83.72 MB (01.83%) ++ image(5472x3648, blob:https://photos.google.com/0c0c673c-3a49-487a-abb7-6b568b0824b3)
│  │  │  ├─────83.06 MB (01.82%) ++ image(5472x3648, blob:https://photos.google.com/e250048c-97e2-462a-a494-0db47c5a97e2)
│  │  │  ├─────82.92 MB (01.82%) ++ image(5472x3648, blob:https://photos.google.com/1a8808fe-21f6-4c27-a36a-60482556bece)
│  │  │  ├─────82.89 MB (01.82%) ++ image(5472x3648, blob:https://photos.google.com/20995f6a-81e7-41dc-91e5-b744d852d867)
│  │  │  ├─────82.88 MB (01.81%) ++ image(5472x3648, blob:https://photos.google.com/250f2bf5-b5e4-4edc-876c-6dc2876c948a)
│  │  │  ├─────82.53 MB (01.81%) ++ image(5472x3648, blob:https://photos.google.com/12a01252-fdb4-4bc1-bb78-0e0f8ed3f7d9)
│  │  │  ├─────82.18 MB (01.80%) ++ image(5472x3648, blob:https://photos.google.com/36a6d32f-4a01-4fd9-bf9c-0235f785a2ad)
│  │  │  ├─────82.14 MB (01.80%) ++ image(5472x3648, blob:https://photos.google.com/cd97d598-e77e-4e8c-ab74-945f39eca913)
│  │  │  ├─────82.06 MB (01.80%) ++ image(5472x3648, blob:https://photos.google.com/137809e1-e471-476c-800b-609ca77e98e8)
│  │  │  ├─────81.81 MB (01.79%) ++ image(5472x3648, blob:https://photos.google.com/f23f5ded-bf50-4c26-ae7c-1ffa18aa99a3)
│  │  │  └─────81.38 MB (01.78%) ++ image(5472x3648, blob:https://photos.google.com/700e9bb9-c8fd-4f6c-8ec1-8458d4fde8a0)
│  │  └──────0.10 MB (00.00%) ++ vector/used
│  └──────0.05 MB (00.00%) ── chrome/vector/used/image(15x15, chrome://global/skin/icons/resizer.svg)/source

Comment 8

[Eric Rahm [:erahm]]

This might make more sense in workers. It seems possible we're not processing data fast enough on the worker threads and memory is backing up.

Comment 9

[Eric Rahm [:erahm]]

Andrew, do you have any ideas here?

Comment 10

[Eric Rahm [:erahm]]

(In reply to Eric Rahm [:erahm] (ni? for phab reviews) from comment #9)

Andrew, do you have any ideas here?

Yaron, maybe you can help?

Comment 11

[Yaron Tausky [:ytausky]]

It's hard to say something without looking at what the worker is doing. Unfortunately I don't think I can look into it in the near future, but I'll keep this in mind.

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

I had a summary that regrettably got lost when I declared tab bankruptcy. The tl;dr is that a possible candidate is bug 1216175 which I was trying to prepare a concise explanation of where we left it (and some extra detail/repro), but that too got lost in tab bankruptcy. Basically, the patch is likely fine, but wasn't able to land due to oranges where it appears it exacerbates some platform thread shutdown issues where nsThread thinks the thread is shutdown because it messaged back and so gecko shutdown continues, but the thread wasn't actually shutdown (we don't join on the thread), so when the thread actually hits full pthread-level shutdown and the RAII stuff about thread-local-storage involving PBackground goes to clean up, assertions start exploding.

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

We've made a number of systemic improvements in worker GC behavior in the past year or two, if not before (but it's also believable that Google Photos has changed their JS behavior to improve things too). In particular, I would expect bug 1216175 to have addressed this for a worker that's continually active in a way that kept rescheduling the GC timers into the future.

Reporter, are you still seeing memory usage behavior like this?

Comment 14

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:asuth, since the bug has recent activity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit BugBot documentation.

Comment 15

[Andrew Sutherland [:asuth] (he/him)]

Marking incomplete, please feel free to reopen/comment here and we can reopen.