We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now


Memory info

sgaucho asked
Medium Priority
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 ?

Watch Question

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.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
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.

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.


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 ?

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


I am still hoping for some clarification as per my post above..
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/libc.so).   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" http://www.solarisinternals.com/si/index.php.  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
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.