Oracle Instances and real memory consumption on Linux and Solaris

There’s a way to know the REAL memory usage by Oracle Instance, including all connecting processes and using the shell rather than a connection to oracle?

The short answer is “I think so” ๐Ÿ™‚

Summing up RSS column from ps output, is not reliable because Linux uses a copy-on-write on process forks and also doesn’t take into account correctly the shared memory and other shared allocations.

I’ve come across this post on Pythian’s Blog from Marc Billette.

While it seems good I’ve had discording results depending on platform and release.

Instead, I’ve tried to create a shell snippet that always uses pmap but works differently and SEEMS to work correctly on Linux ans Solaris.

Basically, using the pmap script I get a lot of information about the different memory areas allocated to the process:

 

Initially I’ve tried to decode correctly the different kinds of memory the same way other scripts I’ve found online do:

but finally the ADDRESS is the same from different processes when the memory area is shared, so my script now just get a unique line for each address and sums up the memory size (not the rss one!):

This should give the total virtual memory allocated by the different Oracle instances.

The results I get are plausible both on Linux and Solaris.

Example:

If you find any error let me know and I’ll fix the script!

Ludovico

The following two tabs change content below.

Ludovico

Oracle ACE Director and Computing Engineer at CERN
Ludovico is an Oracle ACE Director, frequent speaker and community contributor, working as Computing Engineer at CERN, the European Organization for Nuclear Research, in Switzerland.

6 thoughts on “Oracle Instances and real memory consumption on Linux and Solaris

  1. Hi Ludovico,

    The more I read about memory usage the more complicated it becomes. I’m not sure, but I don’t think this is entirely accurate.

    I think “pmap ” shows the virtual memory mappings for each process, which is not the real used memory. see here:

    [root@s1 ~]# pmap 11203 | grep libc-2.5.so
    000000331e000000 1340K r-x– /lib64/libc-2.5.so
    000000331e14f000 2044K —– /lib64/libc-2.5.so
    000000331e34e000 16K r-x– /lib64/libc-2.5.so
    000000331e352000 4K rwx– /lib64/libc-2.5.so

    [root@s1 ~]# pmap -x 11203 | grep libc-2.5.so
    Address Kbytes RSS Dirty Mode Mapping
    000000331e000000 1340 480 0 r-x– libc-2.5.so
    000000331e14f000 2044 0 0 —– libc-2.5.so
    000000331e34e000 16 16 8 r-x– libc-2.5.so
    000000331e352000 4 4 4 rwx– libc-2.5.so

    The outputs from “pmap ” match the Kbytes from “pmap -x ” which is the virtual memory. I also observe RSS (which should be the real used memory” is a lot smaller then virtual memory in some cases – like the one above. Could it be oracle process hasn’t loaded the whole library into the memory, but just a portion?

    Another thing. Have a look at a process from another DB instance:
    [root@s1 ~]# pmap -x 32103 | grep libc-2.5.so
    000000331e000000 1340 480 0 r-x– libc-2.5.so
    000000331e14f000 2044 0 0 —– libc-2.5.so
    000000331e34e000 16 16 8 r-x– libc-2.5.so
    000000331e352000 4 4 4 rwx– libc-2.5.so
    [root@s1 ~]# ps -ef | egrep “11203|32103”
    oracle 11203 1 0 Nov15 ? 00:01:38 ora_qmnc_PROD1
    oracle 32103 1 0 Nov11 ? 00:02:31 ora_rsmn_CAT1

    The memory addresses are the same, so the libraries are shared even among instances.

    And the last one – you also mentioned “copy-on-write”, there’s one one specific thing about it with “anonymous memory”, if I understand the concept correctly, the memory is physically used only by the dirty buffers, otherwise it’s all linked to a single page of /dev/zero. Read more about it here http://landley.net/writing/memory-faq.txt

    So:
    – the idea is very nice to sum up memory based on unique addresses across all platforms
    – need to be careful with shared libraries as they can be used by multiple instances (not a big deal as the size is not big though)
    – I think RSS should be used instead of virtual memory for the calculations.
    – careful with “[ anon ]” segments, need to count dirty pages only.
    – I read quite a lot about the memory management recently, but I have a feeling I understand around 10%, so I might be wrong too.

    Maris

  2. Hi Maris, thank you for sharing your thoughts!
    I was aware of being counting more than once the size of shared libraries… I should calculate separately the total rather than summing up all the memory consumption from the different instances.

    I think I’ll spend a little more time on different memory areas (based on the address) to see if I can find any correlation between the VM Size and the multiple different RSS sizes I get from each process.

    However I’ve big problems with pmap -x on solaris, it takes a huge amount of time and sys cpu consumption on heavy loaded systems so I can’t run it on customer environments. Using pmap without the -x was “quick & dirty” and the results are almost plausible.

    Let me know if you discover more! ๐Ÿ˜‰

    Ludovico

  3. oracle@w1676apypk008:~/Mir> ./test_mem.sh
    TESPRISM : 0
    TESARCH : 0
    TESADHOC : 0
    DEVPRISM : 0
    DEVARCH : 0
    DEVADHOC : 0
    TRAARCH : 0
    TRAADHOC : 0
    TRAPRISM : 0
    total : 0

  4. Hi Mir,
    your Oracle instances are very lightweight ๐Ÿ™‚
    Jokes apart, you should try to reproduce each step in the script to see if it fits with your OS/version.
    On Linux 6 and Solaris 10 works pretty well, but maybe in your environment there is something that prevents it from working.
    Particularly, I expect something not working here:
    mem=pmap $pids 2>&1 | grep "K " | sort | awk '{print $1 " " substr($2,1,length($2)-1)}' | uniq | awk ' BEGIN { sum=0 } { sum+=$2} END {print sum}'


    Ludovico

  5. Hi, Mir,

    Maybe it lacks privileges to run pman. Try “sudo pmap” or log in as root.

    Regards,

    Flรกvio.

  6. Good script . After running the script I got out put as well as compared with actual oracle using . Login to each database and executed my own script how much is using

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.