Memory info

Posted on 2006-03-24
Last Modified: 2013-12-27

I am trying to obtain info regarding a solaris server´s memory.

I have used VMSTAT, PRSTAT, TOP, GLANCE and CACTI so far.     Each of them give a different value/ percentage. I understand that some give a reading of SWAP, other Virtual  and so on..

BUT, which is the one I can actually rely on ? I am implementing a monitoring system using Nagios and this value will be sent to a helpdesk team and I want to be absolutely sure of what I am sending..

Can anyone please help me out ?

Question by:sgaucho
    LVL 3

    Accepted Solution

    According to Cockcroft & Pettit, how much memory is consumed isn't really a good measure of how much memory is needed for a  machine.  A scan rate (sr in vmstat) in the hundreds and thousands indicates insufficient memory though.  So getting a % memory used isn't really all that useful if they are looking for a machine that is in trouble, there is some stuff out there that some systems normally have high scan rates when running stuff like Lotus Domino, but if you get some baseline info I think scan rate will be more useful.  vmstat's free column is probably the best way to get a "number" but like I said it's likely to lead to someone calling you when a system looks like it's running out of memory when it may be operating fine.

    LVL 1

    Expert Comment

    Please try following:
    #prtconf |grep Memory ---to get total physical memory

    #swap -l  ---To get total virtual memory of system.

    #ps -e0pid,vsz,args|sort +1n|tail ---to get memory utilization processwise

    #use vmstat 20 ---to get system memory utilization every 20 sec

    Hope this will serv your requirement.
    LVL 10

    Expert Comment

    As sheetbird suggests, Scan Rate is the better variable to watch. If a system has adaquate memory, the scan rate should always be 0.  "Paging" will ALWAYS occur on pretty much any UNIX system.  If you "cat" a file, you do some number of page-ins.  If you write a file, you generally do some number of page outs.

    Page scanning from time to time isn't going to hurt you.  Page scanning for extended periods of time will.  The "free" column in vmstat will always gravitate to a point in memory known as LOTSFREE for numerous factors - the large contributor to this behavior is the FS Page Cache.  The FS Page Cache caches file system related content into memory.  Reading something from memory is orders of magnitue faster then reading from disk.  LOTSFREE is point where the page daemon gets more aggresive at looking for pages that can be freed and when it finds these pages it pages them out by force (first to anonymous memory followed by phsyical swap) - based on a specific set of rules.  This activity is what shows up as your scan rate - it only happens when free memory hits LOTSFREE and goes lower.  There are two other points of memory utilization that make the page daemon gets very *more* aggressive:  DESFREE and MINFREE.  Course you hits these two points, you'll know it.  By the time you hit DESFREE, you system may be page thrashing.  MINFREE and your system may be swap thrashing.


    swap -l give PHYSICAL swap space.  swap -s shows virtual memory available (physical swap + anonymous memory) which changes dynamically (because of anonymous memory).

    #ps -e0pid,vsz,args|sort +1n|tail ---to get memory utilization processwise - KINDA and at the same time not really for something like sgaucho is asking for.

    Author Comment

    hi guys,

    Thanks for the responses. The output for my VMSTAT is as fwg:

    bash-2.05$ vmstat
     kthr      memory            page            disk          faults      cpu
     r b w   swap  free  re  mf pi po fr de sr m1 m1 m1 m2   in   sy   cs us sy id
     0 0 0 4589944 937552 210 239 1248 1 1 0 0  0  0  0  0  104  311  291 10  4 86

    Accd to the above I have approx 920 Mb of Free Memory. However, I was informed earlier today that this memory is RAM + FileSystem Cache and doesnt reflect the actual free memory of the system.

    Some clarification please ?
    LVL 7

    Expert Comment

    No comment has been added to this question in more than 21 days, so it is now classified as abandoned.
    I will leave the following recommendation for this question in the Cleanup topic area:

    Split: sheetbird & Nukfror

    Any objections should be posted here in the next 4 days. After that time, the question will be closed.

    EE Cleanup Volunteer

    Author Comment

    I am still hoping for some clarification as per my post above..
    LVL 10

    Assisted Solution

    sgaucho, sorry I totally missed your last post.

    Technically, that's true.  The FS Page Cache will consume all memory on a system up to LOTSFREE.  But you *want* it too.  Finding a page of something in memory and accessing it is *magnitudes* of order faster then looking for it on disk and accessing.  When the system being looking for pages to "steal" as memory hits LOTSFREE, the *first* thing that gets stolen are pages from the FS Page Cache.  Basically pages that are flagged read-only shared e.g. pages from program binaries (e.g. /usr/bin/ls), shared library pages (e.g. /usr/lib/   When memory pressure gets higher, pages flagged private (e.g. stack and heap pages for example) will be phsyically paged out to swap.  Higher pressure and entire application address spaces get "swapped" out to physical swap.

    The topic of the Solaris Virtual Memory model is a rather detailed discussion.  The model has changed in partically every major release of Solaris.  Solaris 7 was different then 8 was different then 9 is different then Solaris 10.  It a moving target but Sun is always trying to move towards the best solution for *most* workloads.

    If you want to really understand how virtual memory works on Solaris (at least through Solaris 9), I strongly recommend you goto your local Borders or Barnes&Nobel and take a look at "Solaris Internals"  As you'll see from this web page, there is an update coming (and a new book !!!! - can't freak'n wait !!!).

    If you want a short cut, free memory hitting LOTSFREE and causing your scan rate to be non-zero isn't necessarily a bad thing.  A none-zero scan rate that causes disk IO over long periods of time is a bad thing.

    Some folks may say add more swap space but this doesn't necessarily buy you much besides more disk IO.  A non-zero scan rate causing swap space disk IO can only be resolved by:

    - Addressing the under lying application memory consumption issue
      - Memory leak
      - Application/Environment architecture needs to be reviewed and possibility scaled back
    - Buy more memory

    Featured Post

    Enabling OSINT in Activity Based Intelligence

    Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

    Join & Write a Comment

    Suggested Solutions

    I have been running these systems for a few years now and I am just very happy with them.   I just wanted to share the manual that I have created for upgrades and other things.  Oooh yes! FreeBSD makes me happy (as a server), no maintenance and I al…
    Using libpcap/Jpcap to capture and send packets on Solaris version (10/11) Library used: 1.      Libpcap ( Version 1.2 2.      Jpcap( Version 0.6 Prerequisite: 1.      GCC …
    Learn several ways to interact with files and get file information from the bash shell. ls lists the contents of a directory: Using the -a flag displays hidden files: Using the -l flag formats the output in a long list: The file command gives us mor…
    Learn how to find files with the shell using the find and locate commands. Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:

    729 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    22 Experts available now in Live!

    Get 1:1 Help Now