SUMMARY: solaris10 my freemem is dropping by my procs are not growing (much)

From: Mark Inaba <>
Date: Wed May 27 2009 - 23:58:19 EDT
thanks to David Magda

he pointed me to a reference that said it was due to:
Sun Bug ID = 6385229
Veritas eTrack = 568803

this looks like what i'm experiencing.
i'm using vxfs and it is 4.1
the workaround is to add to /etc/system
set vfs_vnode_path=0

or to add a patch, in my case because i'm sol10 x86 is
Document Audience: PUBLIC
x86 (could not find a there one for x86?) code02 is mp1 i think
Document ID: 125853-01
Title: VRTSvxfs 4.1MP1RP1_x86: Rolling Patch for File System 4.1MP1
Copyright Notice: Copyright \251 2008 Sun Microsystems, Inc. All Rights
Update Date: Thu Oct 18 05:18:37 MDT 2007
Keywords: vxfs 4.1mp1 veritas file system rolling patch 01Summary:
VRTSvxfs 4.1MP1RP1_x86: Rolling Patch for File System
 4.1MP1Date:  Oct/18/2007Installation Requirements:Reboot after
installation, an alternative may be in Special Install I
nstructionsSolaris Release: 10_x86Sun OS Release: 5.10_x86Unbundled
Product: Veritas VxFSUnbundled Release: 4.1MP1Xref:
Topic: VxFS 4.1MP1 RP1 Multiple Fixes PatchRelevant Architecture: i386

i'm going to try the /etc/system method first and watch for downward
drift. i'm hopeful!


-----Original Message-----
From: Mark Inaba
Sent: Wednesday, May 27, 2009 8:52 PM
To: ''
Subject: solaris10 my freemem is dropping by my procs are not growing

hi sun-managers,

I've found a few references to dropping freemem...but am still
sun-managers, you're my only hope :)

freemem things i saw/read:
Adrian's blog says that it was due to pages still cached but available
and not counted in freemem but
that after solaris 8 vmstat fixed this accounting oversight.

there's a post in sun managers in 2006 by someone who looks like he has
the same mystery
but i didn't see a followup for it

so here's my mystery:
from what i've read, it seems like i really should (for solaris >8) be
able to trust vmstat's freemem.
however, it's dropping.

i've added up all the vsz/size and rss from:
(thankfully they all seemed to be in agreement)

the totals vary over time, and the freemem varies in an inverse fashion
(like a mirror image
when i graph them), but over weeks it steadily drifts down. the graph of
forms a bumpy slope downhill. where is my freemem going? how can i find
where it is hiding?

also after a reboot, freemem drops 4gigs in 5hrs, but comparing ps -ef
from then and now
there's no suspicious sounding processes.

server information:
5.10 Generic_137112-02 i86pc i386 i86pc
System Configuration: Sun Microsystems Sun Fire X4200 Server

my current memory status is:
Memory: 16G phys mem, 9773M free mem, 4103M swap, 4103M free swap
Wed May 27 18:19:18 EDT 2009
grab 16777216 physical, 10009600 freemem, 4201472 swap, 4201472 free
totals: size rsize
grab prstat : 1643596 989356
grab ps     : 1628140 980700
grab top    : 1630396 982592
grab psvsz+freemem= 11637740
grab vmstatfreemem 10032912
lost (physical - procs - freemem)
grab 5139476
swap de sr
grab 12067180 0 0

so i have 16gig ram and 4 gig swap, but my procs add up to about 1.6gig
any suggestions on how to find this dark memory?
also, i'm perhaps confused about how memory is used..since the rss is
about  .6G smaller
than vsz, i took it to mean that 1G is in ram and .6G is in swap..but my
and free swap are the nothing residing on my swap device?

thanks much for any clues and enlightening lessons :)


Visit our website at


Note:  The information contained in this message and any attachment
to it is privileged, confidential and protected from disclosure.  If the
reader of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify the
sender immediately by replying to the message, and please delete
it from your system. Thank you.  NYSE Euronext, Inc.
sunmanagers mailing list
Received on Wed May 27 23:55:54 2009

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:14 EST