[Lustre-discuss] lustre ram usage (contd)
Balagopal Pillai
pillai at mathstat.dal.ca
Mon Dec 24 08:16:12 PST 2007
Thanks Mark. This looks handy. I was about to put a cron job with vmstat
to see how the memory utilization progresses with the early morning rsync .
Since i put another 4G on both OSS today morning, hopefully it should be
enough for its operation.
Regards
Balagopal
Mark Seger wrote:
> If you're really interesting in tracking memory utilization, collectl
> - see http://collectl.sourceforge.net/ - when run as a daemon will
> collect/log all slab data once a minute and you can change the
> frequency to anything you like. You can then later play it back and
> see exactly what is happening over time. As another approach you can
> run interactively and if you specify the -oS switch, you'll only see
> changes as they occur. Including the 'T' will time stamp them as in
> the example below:
>
> [root at cag-dl380-01 root]# collectl -sY -oST -i:1
> # SLAB DETAIL
> #
> <-----------Objects----------><---------Slab Allocation------>
> # Name InUse Bytes Alloc Bytes
> InUse Bytes Total Bytes
> 11:02:02 size-512 146 74752 208 106496
> 21 86016 26 106496
> 11:02:07 sigqueue 319 42108 319 42108
> 11 45056 11 45056
> 11:02:07 size-512 208 106496 208 106496 26
> 106496 26 106496
>
> Since this isn't a lustre system there isn't a whole lot of activity...
>
> -mark
>
> Andreas Dilger wrote:
>> On Dec 23, 2007 18:01 -0400, Balagopal Pillai wrote:
>>
>>> The cluster is made idle on the weekend to look at the
>>> Lustre ram consumpton issue. The ram used during yesterday's rsync
>>> is still not freed up. Here is the output from free
>>> total used free shared buffers
>>> cached
>>> Mem: 4041880 3958744 83136 0 876132
>>> 144276
>>> -/+ buffers/cache: 2938336 1103544
>>> Swap: 4096564 240 4096324
>>>
>>
>> Note that this is normal behaviour for Linux. Ram that is unused
>> provides
>> no value, so all available RAM is used for cache until something else is
>> needing to use this memory.
>>
>>
>>> Looking at vmstat -m, there is something odd. Seems like
>>> ext3_inode_cache and dentry_cache seems to be the biggest occupants
>>> of ram. ldiskfs_inode_cache comparatively smaller. -
>>>
>>> Cache Num Total Size Pages
>>> ldiskfs_inode_cache 430199 440044 920 4
>>> ldlm_locks 10509 12005 512 7
>>> ldlm_resources 10291 11325 256 15
>>> buffer_head 230970 393300 88 45
>>>
>>
>>
>>> ext3_inode_cache 1636505 1636556 856 4
>>> dentry_cache 1349923 1361216 240 16
>>>
>>
>> This is odd, because Lustre doesn't use ext3 at all. It uses ldiskfs
>> (which is ext3 renamed + patches), so it is some non-Lustre filesystem
>> usage which is consuming most of your memory.
>>
>>
>>> Is there anything in proc as explained in
>>> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ref-guide/s1-proc-directories.html
>>>
>>> that can force the kernel to flush out the dentry_cache and
>>> ext3_inode_cache when the rsync is over and cache is not needed
>>> anymore? Thanks very much.
>>>
>>
>> Only to unmount and remount the filesystem, on the server. On Lustre
>> clients there is a mechanism to flush Lustre cache, but that doesn't
>> help you here.
>>
>> Cheers, Andreas
>> --
>> Andreas Dilger
>> Sr. Staff Engineer, Lustre Group
>> Sun Microsystems of Canada, Inc.
>>
>> _______________________________________________
>> Lustre-discuss mailing list
>> Lustre-discuss at clusterfs.com
>> https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
>>
More information about the lustre-discuss
mailing list