MacOS – Can Google Chrome be blamed for high RAM usage and lagging performance

google-chromemacbook promacosmemory

On my Mac, OS X lags substantially when browsing through Chrome. I've researched things and understand that inactive memory is part of the free memory, that can and should be freed at a moment's notice:

Even opening a new tab, scrolling through Facebook or Gmail makes things slower. I own a Macbook Pro 13" early 2011, 8GB RAM, OS X Mountain Lion.

Can I affect Chrome's use of RAM in any way?

Edit: Thanks @bmike, Great edit! I just want to make clear that I have also fiddled around with plugins and extensions in chrome settings, even chrome://flags. Flash instance is indeed a big problem, so I have flash blocker and chrome's inbuilt flash blocker.

I was wondering whether this has anything to do with having non-mac memory in my MBP?

Best Answer

Here are samples of data from my 13 inch MacBook Pro with 8 GB of RAM before and after opening Chrome:

Mac:~ bmike$ vm_stat
Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free:                         212512.
Pages active:                       931907.
Pages inactive:                     381136.
Pages speculative:                   55403.
Pages wired down:                   515533.
"Translation faults":            521414918.
Pages copy-on-write:               9952178.
Pages zero filled:               465150147.
Pages reactivated:                   93725.
Pageins:                           1567093.
Pageouts:                             6081.
Object cache: 100 hits of 17386036 lookups (0% hit rate)
Mac:~ bmike$ open -a "Google Chrome"
Mac:~ bmike$ vm_stat
Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free:                         136402.
Pages active:                       990000.
Pages inactive:                     392735.
Pages speculative:                   53707.
Pages wired down:                   523945.
"Translation faults":            521638787.
Pages copy-on-write:               9972877.
Pages zero filled:               465252021.
Pages reactivated:                   93725.
Pageins:                           1577678.
Pageouts:                             6081.
Object cache: 100 hits of 17386267 lookups (0% hit rate)

The setup of the test is a system that's been running for 6 days, and is otherwise not misbehaving. Here are the commands I run to make sure the system is in balance:

Mac:~ bmike$ iostat 5
          disk0       cpu     load average
    KB/t tps  MB/s  us sy id   1m   5m   15m
   28.30   9  0.26   2  1 97  0.78 0.61 0.61
    0.00   0  0.00   0  1 99  0.72 0.60 0.60
   32.00   0  0.01   1  1 99  0.66 0.59 0.60
    0.00   0  0.00   0  1 99  0.61 0.58 0.59
^C
Mac:~ bmike$ vm_stat 5
Mach Virtual Memory Statistics: (page size of 4096 bytes, cache hits 0%)
  free active   spec inactive   wire   faults     copy    0fill reactive  pageins  pageout
210871 940704  53319   379363 512550  522503K  9987967  469254K    93725  1579260     6081 
210776 931311  53771   379369 521225     5150       10    32953        0        0        0 
211289 930966  53798   379369 521207     4606        0    57255        0        0        0 
211321 930971  53799   379369 521207     4589        3    45933        0        0        0 
211531 930998  53799   379369 520925    10999        0    77822        0        0        0 

I set Google chrome up to have 10 blank tabs and quit it and then ran the test above to measure exactly how much RAM changes before and after launching it. As you can see, launching Chrome took about 76k free memory pages out for the free pool and caused the inactive pool to grow by about 11.5k pages.

Given these numbers, Chrome seems highly unlikely to be causing a leak itself and your web pages might be causing the load. If you can run these tools in terminal, you'll likely see that your system had other issues with memory management and Chrome is likely the straw that puts the final load on the system before it starts swapping. Look for paging activity before you launch Chrome and also have a look at my answer here on why inactive memory is almost never the actual problem and this post hopefully explains how to convince yourself whether you have an actual problem with the memory manager or a specific program.