New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 34 users
Status: Fixed
Closed: Apr 2013
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Slow memory leak seen when Google Analytics loaded in Chrome with Real Time view
Reported by, Aug 1 2012 Back to list
Chrome Version       : 20.0.1132.57
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: untested
  Firefox 4.x: untested
     IE 7/8/9: untested

What steps will reproduce the problem?
1. Open Google Analytics Real Time View
2. Slow memory leak will eventually build
3. Confirmed multiple times by multiple users, on multiple Operating Systems.

What is the expected result?

Controlled, or reasonable, virtual memory consumption.

What happens instead?

Perpetually escalating virtual memory consumption via a slow virtual memory leak. It is fairly slow, so does take some time to build up to levels that affect modern PCs negatively.

Please provide any additional information below. Attach a screenshot if possible.

UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11

Duplicate of bug reported here: (had typos, so I recreated)  - originally reported Feb 2, 2012. Reported also at . At both locations multiple users have verified the bug, one reporting it also exists on Chrome for Ubuntu, other confirming it with Chrome on Windows.

This mandates a restart of Chrome every day to prevent excessive virtual memory consumption for those of us who leave Google Analytics Real-Time view open all the time. 

Have I tested with IE and other browsers? NO. BUT, either way it is a Google issue, and so not my job to test. I feel I am trying to be helpful to my favorite browser and internet service company (Google) by reporting this anomalous behavior.

Thank you Google for all you do, and I hope you get this fixed up soon ;).

7.1 KB View Download
we solved this with a script that kills and relaunches chrome every hour. seems to work ok so far.
On my up-to-date Ubuntu, the memory leak is worse. It crashes the Google Analytics tab in less than 3 hours, after consume more than 1GB.
take about 10GB of my memory and crash
Completely killing and relaunching Chrome every hour as says is a work around, but is anyone at Google paying attention here? Now that the real time view is available, I think many web masters use it as a sort of 'web server monitor'. Regardless, no memory leak should EVER exist.
Lastly, we are approaching 1 year since I first reported this ... so ... I think it needs at least a response or some attention from Google.
I can confirm this is still an issue in Chrome Version 23.0.1271.60 beta
In my Windows 7 with Chrome 24.0.1312.5 beta-m it happens too. I kill the Google Analytics all the time to free resources.

Looks like nobody cares about this issue.
Comment 8 by, Nov 16 2012
Mine was fine until the update to Chrome 23. Now it leaks quite badly.
I finally found today that this is what was blocking my computer after I switched it on for an hour or so... trust me it took me ages to get to understand that analytics real time was the cause. I tried so many things and, after all, it was THIS... and I am learning through this post that ppl from Google aren't doing anything about it... pffft
It seems the current 'fix' (not really a fix, a work-around) is that Analytics (or Chrome) will eventually refuse to keep updating the page. The leak is still present though. Is nobody paying any attention? Lots of web masters use the real time feature as a casual web server monitoring mechanism. It's great, especially since it also has an Android app.
And whether this should be on the Analytics bug tracker, or Chrome, or both, is unknown - FWIW. Someone needs to test with IE or another browser, but that's not my job, and I assume Google has testers. This issue has been verified over and over again, and persisted long enough. 

So, have at it Google, you have the brightest engineers in the world! Fix this up!
I would like to add a 'me too' to this post. I would rather not force a page refresh, as this introduces the left-hand menu which I prefer hidden on our wallboard. I see that Real-Time has now moved out of beta, so let's get this fixed!
 Issue 112424  has been merged into this issue.
Labels: -Pri-2 -Area-Undefined Pri-1 Area-Internals Stability-Memory Mstone-26 Area-WebKit
Status: Untriaged
Confirmed on Windows XP Professional SP 3, using Chrome 26.0.1386.0 dev-m.
In a matter of ten minutes or so, the memory usage of the Real Time tab grows to over 100 MB and so on and keeps on growing.
The longer you run it, the slower your entire system gets.
Comment 15 by, Jan 22 2013
i have the same issue. I have to reload it every so often due the memory leak.
Comment 16 by, Jan 22 2013
I use a plugin for chrome called "Auto reload plus" set it on 5 minutes for the real time page to prevent it from crashing.
Comment 17 by, Jan 24 2013
Status: Assigned
ligi, can we see if we can repro/bisect this?
Tested this issue with Win7 & Linux Precise - Not able to repro.

Repro steps:
1. Open Google Analytics Real Time View (
2. Navigate to Task manager and observe the analytic's tab memory usage for few mins(~15 mins)

Tested Chrome Versions: Latest Canary#26.0.1392.0, Dev#26.0.1386.0, Beta#25.0.1364.45 & Stable#24.0.1312.56

Thank you!
Are you confident in those test results? This is something that has been confirmed over and over, and I am looking at excessive memory use now. Unless something has changed in the development version, I believe you should evaluate it closer. The memory leak may be much slower than what some have indicated, it is slower for me than what your previous tester saw, for instance. 15 minutes may only give you a marginal increase in virtual memory allocation, something that one might want to 'dismiss' as normal increases in virtual memory consumption over time in viewing an active page.
Thinking about it, the rate of the leak may depend on the activity present in the real time view. Anyway, 15 minutes is definitely not sufficient test time unless a problem is seen in that period. If no problem is immediately seen, the test time should be - at least - one hour or more. I'm on Windows 8 x64, though saw this in Windows 7 x64, and others have reported it on virtually all platforms (confirmed here on XP, users report exacerbated problem in linux).
Comment 21 by, Jan 24 2013
agreed on the activity of the page. I'm viewing a high traffic web site with over 100 visitors in real time. My memory leak is very fast. You should make sure you are viewing real time for a high traffic web site.
Here is mine after running on Windows 8 64 Bit on Chrome Stable

I've attached the screen of the Memory Usage.

It's been running for 75 Mins and is over 850MB. 

I'm getting around Pageviews per minute of around 300.

3.2 KB View Download
Comment 23 Deleted
Comment 24 by, Jan 24 2013
I mean 1 M every few seconds. I've been watching it and it just hit 5 min and it's at 300M
Comment 25 by, Jan 24 2013
CPU usage is crazy as well.. Hitting spikes of up to 45% at times.
Comment 26 Deleted
Comment 27 by, Jan 24 2013
I have no visitors/pageviews whatsoever and the memory still increases by 1 MB every five to ten seconds.
Over 100 MB after six minutes.
Garbage collection is sometimes happening, but it decreases the memory by a small amount (10 MB or so every 50 MB).
Windows XP Professional SP 3 (Windows Classic theme) and Chrome 26.0.1386.0 dev-m.
Comment 28 by, Jan 24 2013
I also tried to reproduce in incognito (meaning, without extensions) - still occurring.
Comment 29 by, Jan 24 2013
is there anything we can do to help you developers? Some developer mode we can enable to give you more information of what's going on? I know there is the CTRL-SHIFT J , but i don't know what information we could give you to help, other then we can all reproduce it.
Comment 30 by, Jan 24 2013
I just loaded real time in IE 9 in windows 7. Memory is staying around 72 M and not climbing. So it is a chrome only thing.
Comment 31 by, Jan 24 2013
45 minutes have passed, 400 MB (incognito).
Owner: ----
Status: Untriaged
Tried this in Win  XP , Win 7 & Win 8 systems , using current canary - 26.0.1393.0 , I am not able to reproduce this issue.

Launched a browser session with one renderer - , left the system idle for ~ 1hr , but could not see any memory leakage.I did not have any background apps enabled. But if I browser within the site , the memory increases which seems to be expected. 

Can anyone suggest whether I am missing something?
Comment 33 by, Jan 24 2013
The URL for Real Time view for me is -
Can you try this URL?
I am getting an "internal error" with this link.
Comment 35 by, Jan 24 2013
Could you maybe do a remote control session via skype or something with one
of us.. see it for yourself?
Comment 36 by, Jan 24 2013
You do have tracking profiles, right?
(I left out the profile ID part of the URL because when I tried the mentioned URL, it went to the first tracking profile I had.)

Are you using the new interface (I do not know if the old interface is even active anymore)? maybe you have a new internal dog food version?
Do you want to access the page using my account (contact me directly using GoogleTalk, just add @gmail to my name)?

Maybe this one works?
Comment 37 by, Jan 24 2013
about:gpu (maybe software only mode is leaky?) -

Graphics Feature Status

Canvas: Software only. Hardware acceleration disabled.
Compositing: Hardware accelerated
3D CSS: Unavailable. Hardware acceleration unavailable
CSS Animation: Software only, hardware acceleration unavailable
WebGL: Hardware accelerated
WebGL multisampling: Unavailable. Hardware acceleration unavailable
Flash 3D: Unavailable. Hardware acceleration unavailable
Flash Stage3D: Hardware accelerated
Texture Sharing: Hardware accelerated
Video Decode: Software only, hardware acceleration unavailable
Video: Software only, hardware acceleration unavailable
Panel Fitting: Unavailable. Hardware acceleration disabled.
Force Compositing Mode: Unavailable. Hardware acceleration unavailable

Problems Detected

Drivers older than 2009-01 on Windows are possibly unreliable.: 72979, 89802
Intel drivers older than on Windows XP are possibly unreliable.: 74212
Disable 3D (but not Stage3D) in Flash on XP: 134885
Enable panel fitting capability on ChromeOS only on IVB and SNB Graphics Controllers.
Hardware video decode is only supported in win7+.: 159458
Accelerated 2D canvas is unavailable: either disabled at the command line or not supported by the current system.
Panel fitting is unavailable, either disabled at the command line or not supported by the current system.
Thanks @phistuck . I did not have a tracking profile , created one for testing purpose.

Now I could reproduce this issue , the memory is shooting up, increasing approximately 10 MB /min for the renderer . Don't think that this is related to GPU as the GPU Process remains approximately constant.

Confirmed this in all the channels and also with 20.0.1132.57 ( which the oldest build available)

Builds Used

Steps to Reproduce
1. Launch Chrome
2. Navigate to
3. Create an account( if u do not have one )
4. Navigate to -
5. Watch out for the memory usage in Task Manager
@Karen .. could u pls find an owner for this issue?
Labels: nomedia

Status: Assigned
Karen - who the proper Webkit owner will be for this issue?
We have narrowed the problem and reproduced it taking real-time analytics out of the picture
(using just chrome and google-visualization).

The problem reported there seems to happen in Chrome  23.0 and later.
(It does not happen for Chrome 22.0.1229.94 or Firefox 16.0.2)
Comment 45 by, Feb 28 2013
Owner: ----
Status: Untriaged
Comment 46 by, Mar 5 2013
Status: Assigned
jochen any chance you could help us with this bug?
Project Member Comment 47 by, Mar 10 2013
Labels: -Area-Internals -Stability-Memory -Mstone-26 -Area-WebKit Cr-Content Performance-Memory Cr-Internals M-26
The problem seems to have been resolved in Chrome 26.0.1410.28 beta. 
Please confirm and many thanks to the Chrome-Webkit developers.
Comment 49 by, Mar 19 2013
Seems to be fine using Chrome 27.0.1444.3 canary on Windows Vista Home Premium SP 2.
Project Member Comment 50 by, Apr 1 2013
Labels: -Performance-Memory Stability-Memory
Works here using canary under Ubuntu x64 and Windows 7. Thanks!
Seems to be resolved for me. Thanks!
Comment 53 by, Apr 1 2013
Status: Fixed
Project Member Comment 54 by, Apr 6 2013
Labels: -Cr-Content Cr-Blink
This is still an issue on our Google TV, which is running Chrome 11.  We leave this up in our office to see traffic usage, and I have to refresh the page every day because it crashes.
Looks like this issue is back. I'm using Chrome 30.0.1599.22 beta-m. Can someone confirm this?
Yep. Chromium-31.0.1612.0 have this issue too. After about 2 hours it using almost 9gb ram
Please, create a new issue for this.
This issue never really went away for me, but now it is worse than before.  It used to take about 10 hours to exhibit itself (back in July), and it crashing would just be the page.  It crashes five or six times a day now, and today it started to crash the whole browser now, instead of just the page.

Again, this is for Chrome 11 on our Google TV

It makes more sense to stay on this issue to me; all the history is here.
Chrome 11 on Google TV will probably never get this fix anyway (as long as it does not update to a newer version, in which this issue is fixed).
Chrome 30 or Chromium 31, on the other hand, have much better chances of getting a fix.

Since this issue is closed, the team generally prefer to have a new issue for a regression.

Anyway, I do not believe the Google TV issue is relevant (as long as it stays on Chrome 11).
I can agree the issue is probably different, though related, to what they are seeing, so I'm fine with moving the discussion to another issue.

I'm confused about versioning, though; Chrome 11 is the most up-to-date version available for my Google TV.  Is it not supported, then?  Bugfixes are not back-ported to the GoogleTV version of Chrome?  And there isn't a supported way to get another version of the browser (even an older one) or a different browser onto a Google TV?  I feel like I've been backed into a corner here.  The only thing this TV does in our office is display the Google Analytics page; that's what we got it for...
Google usually does not backport general fixes. It does backport security fixes, I believe.

You could have just plugged in a computer instead. ;)
Raised  Issue 285068  to track new instance of this bug.
As the original reporter, I must admit to jumping the gun in saying 'looks good to me', about the proposed fix. I was busy, am not a Google employee, or Chromium project member, and - well - just assumed they tested their fix :o.

So, the issue does continue. It isn't as bad it used to be (for me), though as we've discussed, the rate of the leak almost certainly depends on the amount of traffic/activity in the real time view.
Status: Fixed? This problem is still very much alive.
It took me quite a while to find out what was slowing down my computer.
I used to have Analytics real time view open all the time. Now i load the page when i want to have a glance at my webshop.

A proper fix would be really appreciated!
I have experienced this problem on a number of occassions. I am a power desktop user and often go without restarting my Windows 7 PC for weeks at a time.

I have witnessed memory usage grow to over 3GB on three separate occassions now. I frequently check Google Analytics in a pinned tab throughout the day, and its often showing the realtime view.

Just this moment I have had to force close the tab as it had increased to 1.5GB and was showing signs of sluggishness.
Further to my last comment, the site in question which I view realtime stats for gets approximately 25k-30k visitors per day, so the realtime stats often show 150-200+ concurrent visitors.
Comment 68 by Deleted ...@, Sep 10 2013
Confirmed this also on Firefox 23.0.1 - same behaviour there. No additional plugins running, only analytics page.
It still happens on Google TV and has been getting worse over the last few weeks. Chrome version 3.2-17544
Comment 70 by Deleted ...@, Sep 12 2013

I'm having the same problem but I've noticed that I'm having that "memory leak" with Firefox too (iceweasel). 

I'm using Debian 7 with Iceweasel 10.0.12. Exactly same thing happens. Now FF uses 1.5GB from memory, and memory fill speed is almost same like Chrome. Maybe it's not Chrome causing the problem. It feels more like google analytics issue.

Screenshot from 2013-09-12 11:25:07.png
19.2 KB View Download
Comment 71 Deleted
Comment 72 by, Sep 14 2013
Same here ! Windows 8 + Chrome: 1500 mb after 2 hours !
Comment 73 by Deleted ...@, Sep 26 2013
Same problem here. Is this something that is solved using another browser? I read someone using Ubuntu? Or doe it not matter which browser you use?
Thanks for your help.
Comment 74 by Deleted ...@, Oct 10 2013
This isn't fixed at all.
How do we get this bug re-opened?
22.7 KB View Download
Comment 76 by, Oct 10 2013
@josh.grebe -
Just create a new issue. You can comment here with a link to the new issue and I will triage it appropriately.
There is an open issue here:!category-topic/analytics/report-bugs/DjI5j5BwPo8

He didn't add a lot of information in the way of a bug report (do they a Jira or something more formal?), but they might take up our case if we take it there.

I would be happy even knowing someone has this on their very long to-do list somewhere in Google's cubicle land...
Comment 79 by, Oct 11 2013
This still seems like an issue with the Google Visualization chart drawing. This is not a Chrome specific leak (but in Chrome the leak is worse than in Firefox).

You can star issue google-visualization-api-issues:1276 or issue issue google-visualization-api-issues:762 for updates.
Labels: Restrict-AddIssueComment-EditIssue
The issue has been fixed over at

Google Analytics will eventually switch to V1.1 of the visualization API.
Let me close this bug.
Sign in to add a comment