Oracle 11gR2 Grid Infrastructure — Memory Footprint

Posted in: Technical Track

DIMMsUpgrading to 11g Release Grid Infrastructure? You probably want to read on…

Oracle 11g Release 2 Grid Infrastructure has been dramatically redesigned compare to 10g and 11gR1 Clusterware. Coming with impressive set of new features, Grid Infrastructure also uses much more memory. While RAM is rather inexpensive these days, it does pose an inconvenience in some scenarios. Particularly, for sand-box type installations that I use all the time for my own tests and demonstrations. For production upgrades, you need to be aware of and plan for increased memory usage.

I’ve been able to easily run a 2 node 10g RAC cluster on my MacBook with 4 GB of RAM allocating less than 1 GB of RAM to each virtual machine. That was even enough for a mini database instance with a very small memory footprint. Oracle 11g Release 1 was pretty much the same except maybe the database instance itself required a bit more memory but one node could still fit within 1 GB of RAM.

In 11gR2, bare-bone Grid Infrastructure processes alone consume 10+ times more memory ( on 32 bit Linux to be precise):

[[email protected] ~]$ ps -eo pid,%mem,rss,user,cmd --sort=rsz --cols 100 | grep -e '^ *PID' -e grid -e ohasd | grep -v grep
 3614  0.0  1080 root     /bin/sh /etc/init.d/init.ohasd run
 4322  0.2  3368 oracle   /nfs/11.2.0/grid/opmn/bin/ons -d
 4323  0.4  5164 oracle   /nfs/11.2.0/grid/opmn/bin/ons -d
 4117  0.6  7860 root     /nfs/11.2.0/grid/bin/oclskd.bin
 3830  0.6  8788 oracle   /nfs/11.2.0/grid/bin/gipcd.bin
 5048  0.7  8992 oracle   /nfs/11.2.0/grid/bin/tnslsnr LISTENER -inherit
 4167  0.7 10052 oracle   /nfs/11.2.0/grid/bin/evmlogger.bin -o /nfs/11.2.0/grid/evm/log/evmlogger.i
 3969  0.9 12412 oracle   /nfs/11.2.0/grid/bin/diskmon.bin -d -f
 3860  0.9 12736 oracle   /nfs/11.2.0/grid/bin/mdnsd.bin
 4067  1.1 14648 root     /nfs/11.2.0/grid/bin/octssd.bin reboot
 5016  1.2 15860 root     /nfs/11.2.0/grid/bin/orarootagent.bin
 3956  1.3 16964 root     /nfs/11.2.0/grid/bin/orarootagent.bin
 4292  1.4 17984 oracle   /nfs/11.2.0/grid/bin/oraagent.bin
 3874  1.5 20112 oracle   /nfs/11.2.0/grid/bin/gpnpd.bin
 3817  1.5 20300 oracle   /nfs/11.2.0/grid/bin/oraagent.bin
 4083  1.8 23700 oracle   /nfs/11.2.0/grid/bin/evmd.bin
 4372  2.4 31548 oracle   /nfs/11.2.0/grid/jdk/jre//bin/java -Doracle.supercluster.cluster.server=eo
 3564  3.2 41532 root     /nfs/11.2.0/grid/bin/ohasd.bin reboot
 4081  3.5 44932 root     /nfs/11.2.0/grid/bin/crsd.bin reboot
 3906 18.6 239428 root    /nfs/11.2.0/grid/bin/cssdagent
 3887 18.6 239444 root    /nfs/11.2.0/grid/bin/cssdmonitor
 3924 20.1 258564 oracle  /nfs/11.2.0/grid/bin/ocssd.bin

The second column above gives you amount of resident memory in KB for processes related to Grid Infrastructure. As you can cleanly see, processes of CSS components consume well above 700MB! In total we can account for 1 GB. (those calculations are flawed — see below)

Compare that with 10g ( on 32 bit Linux) — bare-bone Clusterware processes consume only 60MB:

[[email protected] ~]$ ps -eo pid,%mem,rss,user,cmd --sort=rsz --cols 100 | grep -e '^ *PID' -e nfs -e crs -e css -e evm | grep -v grep
 6524  0.0  348 oracle   /nfs1/oracle/oracle/product/10.2.0/crs/opmn/bin/ons -d
 4892  0.1  992 oracle   /bin/sh -c cd /nfs1/oracle/oracle/product/10.2.0/crs/log/lh1/cssd/oclsomon;
 3262  0.1 1072 root     /bin/sh /etc/init.d/init.evmd run
 3506  0.1 1100 root     /bin/sh /etc/init.d/init.crsd run
 4575  0.1 1116 root     /bin/su -l oracle -c sh -c 'ulimit -c unlimited; cd /nfs1/oracle/oracle/pro
 4890  0.1 1120 root     /bin/su -l oracle -c /bin/sh -c 'cd /nfs1/oracle/oracle/product/10.2.0/crs/
 4664  0.1 1180 root     /bin/sh /etc/init.d/init.cssd oclsomon
 3263  0.1 1188 root     /bin/sh /etc/init.d/init.cssd fatal
 4677  0.1 1188 root     /bin/sh /etc/init.d/init.cssd daemon
 6525  0.5 4792 oracle   /nfs1/oracle/oracle/product/10.2.0/crs/opmn/bin/ons -d
 4922  0.6 5224 oracle   /nfs1/oracle/oracle/product/10.2.0/crs/bin/oclsomon.bin
 5915  0.7 6280 oracle   /nfs1/oracle/oracle/product/10.2.0/crs/bin/evmlogger.bin -o /nfs1/oracle/or
 4576  1.1 9312 oracle   /nfs1/oracle/oracle/product/10.2.0/crs/bin/evmd.bin
 5018  1.1 9428 oracle   /nfs1/oracle/oracle/product/10.2.0/crs/bin/ocssd.bin
 4606  2.0 16712 root    /nfs1/oracle/oracle/product/10.2.0/crs/bin/crsd.bin reboot

The memory usage above is a bit overstated. There are some shared memory accounted multiple times. I could use Smaps interface to get better per process statistics. For example, you could see that 3 of the “top offenders” (CSS binaries) have about 40MB of shared libraries each:

[[email protected] ~]# ./ 3924 | head
VMSIZE:     258576 kb
RSS:       258564 kb total
            39164 kb shared
             5180 kb private clean
           214220 kb private dirty
     vmsize   rss clean   rss dirty  file
   15052 kb        0 kb    15052 kb
   12016 kb        0 kb    12016 kb
   11184 kb        0 kb    11184 kb
[[email protected] ~]# ./ 3887 | head
VMSIZE:     239456 kb
RSS:       239444 kb total
            40096 kb shared
             6200 kb private clean
           193148 kb private dirty
     vmsize   rss clean   rss dirty  file
   14624 kb        0 kb    14624 kb
   10240 kb        0 kb    10240 kb
   10240 kb        0 kb    10240 kb
[[email protected] ~]# ./ 3906 | head
VMSIZE:     239440 kb
RSS:       239428 kb total
            40096 kb shared
             6200 kb private clean
           193132 kb private dirty
     vmsize   rss clean   rss dirty  file
   14624 kb        0 kb    14624 kb
   10240 kb        0 kb    10240 kb
   10240 kb        0 kb    10240 kb
[[email protected] ~]#

One way to get a practical number is to check system memory usage with and without Grid Infrastructure running — the difference is about 750MB (see the “free” column of the second row).

[[email protected] ~]# free
             total       used       free     shared    buffers     cached
Mem:       1283040    1131584     151456          0      18504     295668
-/+ buffers/cache:     817412     465628
Swap:       655328         76     655252
[[email protected] ~]# crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'cheese1'
CRS-4133: Oracle High Availability Services has been stopped.
[[email protected] ~]# free
             total       used       free     shared    buffers     cached
Mem:       1283040     397144     885896          0      18640     316632
-/+ buffers/cache:      61872    1221168
Swap:       655328         76     655252
[[email protected] ~]# ps -eo pid,%mem,rss,user,cmd --sort=rsz --cols 100 | grep -e '^ *PID' -e grid -e ohasd | grep -v grep
 3614  0.0  1084 root     /bin/sh /etc/init.d/init.ohasd run

I don’t have 11gR1 test cluster handy so I can’t check 100% but Oracle 11g Release 1 Clusterware is not much different from 10g so memory usage must be similar.

The lesson is that if you are upgrading your Oracle RAC Cluster to 11gR2 from 10g or 11gR1, then you have to account for additional 700MB memory for Grid Infrastructure alone on each node. Note that, this doesn’t take into account higher memory usage of the database instances themselves.

Want to talk with an expert? Schedule a call with our team to get the conversation started.

About the Author

What does it take to be chief technology officer at a company of technology experts? Experience. Imagination. Passion. Alex Gorbachev has all three. He’s played a key role in taking the company global, having set up Pythian’s Asia Pacific operations. Today, the CTO office is an incubator of new services and technologies – a mini-startup inside Pythian. Most recently, Alex built a Big Data Engineering services team and established a Data Science practice. Highly sought after for his deep expertise and interest in emerging trends, Alex routinely speaks at industry events as a member of the OakTable.

11 Comments. Leave new


It was a surprise to me also. I was doing VMware RAC installations of 10gR2 and 11gR1 with 1G RAM per VM with no worries. You can do the 11gR2 equivalent with 2G RAM per VM, but it’s better if you do 2.5G+.

Even in production environments this can be an issue. If you are running 11gR1 RAC and the kit is maxed out with memory (no more slots), how do you upgrade to 11gR2 without a hardware upgrade?

The issue for me is this change comes in the terminal release, not a new version. People wanting long term support on 11g need to upgrade to 11gR2, but that may force a hardware upgrade. Not nice.




Upgrading to 11g Release Grid Infrastructure? You probably want to read on…

Planning demos of 11g Release 2 Grid Infrastructure? You probably want to read on …

You have my sympathy!


This is disappointing. It is amazing that we ran enterprise software on a lot less memory not too long ago.
The fact that memory is cheaper shouldn’t be a license to unbuckle the belt on memory hogging software. I liken this to overeating just because food is cheaper.

Alex Gorbachev
March 7, 2010 8:05 pm

@Tim: Well, “terminal release” is very relative. In regards to Oracle Clusterware, it was terminal release in 11gR1 because 11gR2 has completely new stuff under the hood.

@Doug: No. No demos on 11gR2 RAC – it hardly fits on my Mac and I couldn’t risk it going wrong.

Peter Shand
March 8, 2010 2:49 pm

Thank you, this explains a lot!

I won’t waste any more time trying to install a sandbox 11gR2 RAC in vm’s. I was able to run the grid install on a 4 gig box, but it was very slow, and debugging was practically impossible. I am now encouraged to retry with 11gR1 or 10GR2.


With 11gR2 I am back to a single instance rac on my laptop. Not the best for demos, but at least you can test your scripts…

Bernhard de Cock Buning
March 15, 2010 5:00 am


There is a workaround to decrease the memory usage.

After installation update the ohasd in each of the GRID homes. Add: ulimit -Ss like this:

[[email protected] ~]# vi /u01/app/11.2.0/grid/bin/ohasd

# forcibly eliminate LD_ASSUME_KERNEL to ensure NPTL where available
ulimit -Ss

The result, it will same around 500MB of memory.

You still need more memory in compare to 11gR1, but at least it will same 1G for 2 nodes.


Thanks Alex for a wonderful article and to all others who contributed.

@Bernhard- Is your suggestion documented somewhere? Like a metalink note or something?

Blogroll Report 05/02/2010 – 12/03/2010 « Coskan’s Approach to Oracle
April 22, 2010 8:07 pm

[…] 1-How is 11GR2 Grid Infrastructure memory footprint-possible solution to decrease memory Alex Gorbachev-Oracle 11gR2 Grid Infrastructure — Memory Footprint […]

Vishal Gupta
April 23, 2010 7:36 am

Incorrect ulimit setting problem with 11gR2 grid infrastructure is due to bug 9084067 (Metalink Note 983715.1). The bug will be fixed in

Ben Prusinski
May 15, 2010 7:21 pm

Yep its a pig thats for sure compared to 11gR1 and 10gR2 RAC. I am waiting for prices on laptops to come down that have 8-16Gb of RAM so that I can setup and run 11gR2 RAC. Unfortunately, by then Oracle 12g will require even more RAM.


Leave a Reply

Your email address will not be published. Required fields are marked *