New issue
Advanced search Search tips

Issue 760774 link

Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 763577
Owner: ----
Closed: Sep 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Repeatedly-loading ads causing multiple GB memory usage, constant high CPU usage, and constant network requests

Project Member Reported by ddorwin@chromium.org, Aug 30 2017

Issue description

Chrome Version: 60.0.3112.101, 62.0.3199.0
OS: Linux, Windows, Mac

What steps will reproduce the problem?
(1) Open any article from http://www.scarymommy.com/. For example, http://www.scarymommy.com/study-shows-drinking-coffee-longer-life/.
(2) Leave the tab open.
(3) Optionally, open another tab in the same window.

What is the expected result?
After the page loads, it should be using little to no CPU and network, and memory should not grow.

What happens instead?
Constant high CPU usage, frequent periodic network requests that add up to 10s of MB, and memory usage grows to multiple GB. In one case, over 3.3 GB of memory, 100 MB transferred, and 100% CPU according to Chrome's Task Manager (Linux).

The network requests are to a small set of ad network origins and many are for the exact same files.

Please use labels and text to provide additional information.
Anecdotally, memory growth seemed faster on Chrome 60 on Linux. However, Chrome 62 on Mac also exceeded 2 GB.

Memory use in Firefox 55.0.2 (64-bit) on Linux grew to over 5.3 GB.

On Safari 10.1.2 on Mac, however:
* When the tab is focused, memory usage appears to grow more slowly.
* When the tab is not focused, memory usage does not appear to grow and the tab uses essentially 0% CPU.

While the root cause is in the application space, is there something Chrome can do to minimize the impact of the problem for users? Why is the issue less severe in Safari? Can Chrome limit the impact when the tab is not focused?
 
Labels: -Pri-3 OS-Linux OS-Mac OS-Windows Pri-2
I am able to reproduce this issue on current stable#60.0.3112.113 for Win7 64-bit, here is the attached trace.
trace_760774.json.gz
7.4 MB Download
Labels: M-62
Observing the similar behavior starting Chrome# 50.0.2658.0 on Win7 64-bit.
We are seeing the same issue on some Windows 2012 R2 Citrix Xenapp 7.8 servers with published Chrome 60.0.3112.113. Actually it ends up freezing the server and user sessions after some time. Since we can't login to the server any longer, the only solution is to force reboot the server. If I am logged into the server when it happens, I can use powershell to kill the Chrome process and it returns to normal. We are now considering deploying pi-hole to eliminate the ads.
The Citrix issued mentioned in comment #3 is almost certainly a separate issue. This was an audio-system spin-lock priority inversion that is discussed in  crbug.com/754213 . It has been fixed but the fix has not made it to stable yet.

I checked the page in Edge and it consumes significantly more memory and CPU time than Chrome does - it grew to over a GB in just a couple of minutes.

As was said in the initial report this is a problem with the web page. Yes, there are mitigations which can help to slow the memory growth and reduce CPU consumption of inactive pages. For instance, if another tab is opened in the same window such that the scarymommy page is no longer visible then its process priority goes to low and its CPU consumption plummets. This is due to mitigations which Chrome uses to try to correct for badly behaved background pages, while still making foreground pages behave as intended. Minimizing the window containing the page also lowers its priority and its CPU usage.

So... we could consider mitigations more aggressively, specifically when a tab is visible but not in focus. There are separate bugs for this and we should link this bug to the main bug or dup this bug to that one.

Cc: altimin@chromium.org
Mergedinto: 763577
Status: Duplicate (was: Untriaged)
This idea (throttling inactive windows or those with no user interaction) is being tracked in bug 763577.

Sign in to add a comment