1945048 - severe browser lags and high CPU and RAM usage on vk.com

Status: REOPENED

(Core :: Performance: General, defect)

Description

[Pasha]

Attachment: memory-report.json.gz

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

Download production version 134.0.2. open several tabs and use a browser.

Actual results:

high CPU and RAM load

Expected results:

normal use of resources

Comment 1

[:Gijs (he/him)]

Doesn't look like this is a security issue and the memory report is anonymized so I'm going to open this up.

Can you elaborate on which processes you think are using too much RAM and what you're basing this on? As a counterexample, I see 2 or 3 processes in the memory report using about 1MiB of RAM so I assume it's not those... The parent process seems to be using about 400MiB which is not nothing but IMO also not loads... so it's not clear to me exactly how big you perceive the problem to be (ie where you're checking total memory use and what you're seeing). You've also not said which sites you're opening - at least one of them has started a bunch of worker threads and is using a lot of memory that way, and from the graphics process my suspicion is at least some of the sites might be using quite a lot of large images or other gpu resources - but of course it's impossible to know without knowing what "several tabs" refers to.

Also, for CPU use the memory report doesn't help us - please could you share a performance profile using https://profiler.firefox.com/ ?

Comment 3

[BugBot [:suhaib / :marco]]

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.

Comment 4

[Pasha]

(In reply to :Gijs (he/him) from comment #1)

Doesn't look like this is a security issue and the memory report is anonymized so I'm going to open this up.

Can you elaborate on which processes you think are using too much RAM and what you're basing this on? As a counterexample, I see 2 or 3 processes in the memory report using about 1MiB of RAM so I assume it's not those... The parent process seems to be using about 400MiB which is not nothing but IMO also not loads... so it's not clear to me exactly how big you perceive the problem to be (ie where you're checking total memory use and what you're seeing). You've also not said which sites you're opening - at least one of them has started a bunch of worker threads and is using a lot of memory that way, and from the graphics process my suspicion is at least some of the sites might be using quite a lot of large images or other gpu resources - but of course it's impossible to know without knowing what "several tabs" refers to.

Also, for CPU use the memory report doesn't help us - please could you share a performance profile using https://profiler.firefox.com/ ?

https://share.firefox.dev/40Fx8RR

Comment 5

[BugBot [:suhaib / :marco]]

This bug was moved into the Performance component.

:suprunchuk, could you make sure the following information is on this bug?

• ✅ For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
• ✅ For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
• Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Comment 6

[Bas Schouten (:bas.schouten)]

Hmm. A 2.2 second jank in the parent process is bad. It seems to be doing very slow layout and style in the parent process. Not sure what's going on there but tentatively redirecting to Firefox who can hopefully work with Pasha to figure out the root cause here. An about:support would be helpful, as well as a profile that includes URLs as there is one very janky website in there somewhere that may be related to the parent process jank.

The Performance Impact Calculator has determined this bug's performance impact to be medium. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: Windows
Impact on browser: Causes noticeable jank

Comment 7

[Matjaz Horvat [:mathjazz]]

Thank you for your report! However, we don’t have enough information to investigate further.

If you can provide the requested details, please feel free to reopen the bug so we can take another look.

Comment 8

[Pasha]

(In reply to Matjaz Horvat [:mathjazz] from comment #7)

Thank you for your report! However, we don’t have enough information to investigate further.

If you can provide the requested details, please feel free to reopen the bug so we can take another look.

raw data https://drive.google.com/file/d/1QPXGsltWmK8heuc9Lakvuq78klWVy95i/view?usp=sharing

Comment 9

[:Gijs (he/him)]

Reopening given the about:support data - thank you!

The performance profile suggests at least one child is hung for 800+ms waiting to ask marionette if it's running, apparently from the webpage accessing Navigator.webdriver. That seems bad. I don't know why that is using sync IPC but it shouldn't. :whimboo, is that on file somewhere?

But of course, the reason it then takes a long time is that the parent is also hung. Most of that seems to be populating the devtools rules view, and as comment #6 says, doing a bunch of layout/style work. That layout/style work actually appears to be coming from a call to scrollTop inside the rule view population code, so also passing this to some devtools folks - I don't know what they would need to dig in deeper.

It would still be really helpful to have more detailed steps to reproduce here. I'm guessing you're using developer tools on some website - are you able to share anything about that website or an isolated testcase that reproduces the problem?

Comment 10

[Pasha]

hi. I do not know what steps lead to this. I suspect this is a problem due to the fact that I use Vkontakte (a Russian social network). Could you check which side of the problem is on? The link https://vk.com/

Comment 11

[Julian Descottes [:jdescottes]]

Moving to triage for devtools. I see 2 seconds spent on the DevTools pagestyle actor for getApplied, which seems to indicate a lot of rules.
Opening vk.com, I can see the ruleview is a bit laggy on my machine even if it doesn't fully freeze.

At the moment the devtools ruleview doesn't implement a virtual viewport or any other trick to properly handle scenarios where it needs to display many rules.

Pasha: To make sure: are you intentionally using DevTools to debug vk.com ?

Comment 12

[Julian Descottes [:jdescottes]]

For reference, the scrollHeight of the ruleview on vk.com is 94999px tall.

Comment 13

[Pasha]

(In reply to Julian Descottes [:jdescottes] from comment #11)

Moving to triage for devtools. I see 2 seconds spent on the DevTools pagestyle actor for getApplied, which seems to indicate a lot of rules.
Opening vk.com, I can see the ruleview is a bit laggy on my machine even if it doesn't fully freeze.

At the moment the devtools ruleview doesn't implement a virtual viewport or any other trick to properly handle scenarios where it needs to display many rules.

Pasha: To make sure: are you intentionally using DevTools to debug vk.com ?

Hi. I'm having problems with closed DevTools. I did not open the debugging of the site, my browser freezes without it just when using it as a "regular user".

Comment 14

[Pasha]

(In reply to Julian Descottes [:jdescottes] from comment #12)

For reference, the scrollHeight of the ruleview on vk.com is 94999px tall.

Maybe it came up when I was just scrolling through the news feed.

Comment 15

[Julian Descottes [:jdescottes]]

(In reply to Pasha from comment #13)

(In reply to Julian Descottes [:jdescottes] from comment #11)

Moving to triage for devtools. I see 2 seconds spent on the DevTools pagestyle actor for getApplied, which seems to indicate a lot of rules.
Opening vk.com, I can see the ruleview is a bit laggy on my machine even if it doesn't fully freeze.

At the moment the devtools ruleview doesn't implement a virtual viewport or any other trick to properly handle scenarios where it needs to display many rules.

Pasha: To make sure: are you intentionally using DevTools to debug vk.com ?

Hi. I'm having problems with closed DevTools. I did not open the debugging of the site, my browser freezes without it just when using it as a "regular user".

Your performance profile indicates that DevTools are open when you recorded it. Maybe they are in a separate window which is somehow in the background? Can you make sure that in Tools > Browser Tools > Web Developer Tools is unchecked?

Or if you mean that you have the issue both when DevTools are open or not, can you record another profile without DevTools open?
(for the DevTools specific issue, I think this is covered by Bug 1903632).

Comment 16

[Pasha]

(In reply to Julian Descottes [:jdescottes] from comment #15)

(In reply to Pasha from comment #13)

(In reply to Julian Descottes [:jdescottes] from comment #11)

Moving to triage for devtools. I see 2 seconds spent on the DevTools pagestyle actor for getApplied, which seems to indicate a lot of rules.
Opening vk.com, I can see the ruleview is a bit laggy on my machine even if it doesn't fully freeze.

At the moment the devtools ruleview doesn't implement a virtual viewport or any other trick to properly handle scenarios where it needs to display many rules.

Pasha: To make sure: are you intentionally using DevTools to debug vk.com ?

Hi. I'm having problems with closed DevTools. I did not open the debugging of the site, my browser freezes without it just when using it as a "regular user".

Your performance profile indicates that DevTools are open when you recorded it. Maybe they are in a separate window which is somehow in the background? Can you make sure that in Tools > Browser Tools > Web Developer Tools is unchecked?

Or if you mean that you have the issue both when DevTools are open or not, can you record another profile without DevTools open?
(for the DevTools specific issue, I think this is covered by Bug 1903632).

Good. Let me record a new profile.

Here are the steps I'm doing

1. open the link https://vk.com/
2. log in to your account.
3. Open the news feed https://vk.com/feed
4. In this step, I have enabled the profiler.
5. I'm doing an F5 refresh of the page. (loading takes about 10 seconds)
6. Scroll down the news feed. I'm just reading the news feed.

The actual result: CPU usage is 100% and other PC parameters are loaded very heavily.

https://share.firefox.dev/41xLa8A

Comment 17

[Julian Descottes [:jdescottes]]

Thanks for sharing another profile. While I no longer see references to files from the DevTools inspector, I can still some activity from the Network monitor. Are you sure you don't have a devtools window open somewhere?

In the meantime, sending back to Firefox General as this doesn't seem related to devtools.

Comment 18

[Mike Conley (:mconley) (:⚙️)]

So with this latest profile, it doesn't look like the parent process is janking at all - instead, it's the web content process at vk.com which appears to be very very busy. Moving back to Core :: Performance so that the newest profile can be reevaluated by the platform team.

Comment 19

[Pasha]

hi. You mean it's really about vk.com and it has nothing to do with the browser?

Comment 20

[Julian Descottes [:jdescottes]]

(In reply to Pasha from comment #19)

hi. You mean it's really about vk.com and it has nothing to do with the browser?

Not really we are just trying to identify the best team to look at the issue. Your initial report pointed to DevTools, but given the latest information you provided we are investigating a different angle.

To be clear the website might be doing something wrong, but at this point we can't really tell.

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

(In reply to :Gijs (he/him) from comment #9)

The performance profile suggests at least one child is hung for 800+ms waiting to ask marionette if it's running, apparently from the webpage accessing Navigator.webdriver. That seems bad. I don't know why that is using sync IPC but it shouldn't. :whimboo, is that on file somewhere?

No, there is no bug about that yet. Thanks for pointing that out. I've now filed bug 1960319.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #21)

(In reply to :Gijs (he/him) from comment #9)

The performance profile suggests at least one child is hung for 800+ms waiting to ask marionette if it's running, apparently from the webpage accessing Navigator.webdriver. That seems bad. I don't know why that is using sync IPC but it shouldn't. :whimboo, is that on file somewhere?

No, there is no bug about that yet. Thanks for pointing that out. I've now filed bug 1960319.

FYI this is now fixed in Marionette and Remote Agent. Both components use shared data now to sync the running state.

Comment 23

[Pasha]

Hi. I see that some corrections have been made. Can you tell me when they will be released? I got an update to stable version 139.0 today, are there any changes here?