Re: Memory keep increasing.

From: Ming (ebullience_at_emails.bjut.edu.cn)
Date: Tue Nov 17 2009 - 22:24:48 CST

ThanksŁĄ

>From: Axel Kohlmeyer <akohlmey_at_gmail.com>
>Reply-To:
>To: Ming <ebullience_at_emails.bjut.edu.cn>
>Subject: Re: namd-l: Memory keep increasing.
>Date:Sun, 15 Nov 2009 09:59:42 -0500
>
>On Sun, 2009-11-15 at 18:14 +0800, Ming wrote:
>
>> Hi Dow,
>> Thanks! As you said, I can run the "sync" command when the NAMD job is runing and this can help me decrease the cached memeory. Am I right? Again, how often should I run this command? Many thanks!
>
>ming,
>
>you are on a wild goose chase. the advice about sync is useless.
>what sync does, has nothing to do with the consumption of memory by
>applications. sync forces outstanding write accesses to be committed
>to disk, but that does _not_ free them from the cache. this is standard
>unix semantincs, and for certain working on linux kernel, which you are
>obviously running.
>
>as i was pointing out before, do you see a steady increase of the memory
>usage (you better monitor the namd2 executable(s) rather than the total
>system memory)? parallel applications that have internal buffers to
>store data that gets passed around (and NAMD qualifies there), usually
>only grow their buffer storage, but do not shrink it for performance
>reasons (freeing and allocating large chunks of memory costs time). for
>NAMD that means that during the equilibration and load balancing phases
>of a simulation the memory usage is likely to go up, but it should
>level out at some point. if it doesn't, it needs further investigation,
>and it would then be imperative that you make your inputs available to
>NAMD developers, so they can check it. ...or you do it yourself, e.g.
>by running your application under the memory checker tool of valgrind.
>
>cheers,
> axel.
>>
>> Ming
>>
>>
>>
>>
>> >>From: Mindspring

>> >>Reply-To:
>> >>To: Ming

>> >>Subject: Re: namd-l: Memory keep increasing.
>> >>Date:Sun, 15 Nov 2009 03:12:43 -0500
>> >>
>> >>XFS is the file system used on an SGI. It caches data heavily in
>> >>RAM. Sync will flush the data to disk.
>> >>
>> >>Sincerely,
>> >>Dow Hurst
>> >>
>> >>On Nov 14, 2009, at 9:28 PM, "Ming"
>> >
>> >>wrote:
>> >>
>> >>> Hi Dow,
>> >>> Thanks for your reply. I'm sorry I don't understand what you said.
>> >>> I'm very poor on runing a on a SGI station. Could you please tell me
>> >>> what XFS mean? I didn'y run sync. Again, I don't know why you ask me
>> >>> to run sync. Do you mean I shold tell the system save some data into
>> >>> hard drive but not buffer?
>> >>>
>> >>>
>> >>> I ran the "free" command and i didn't find out any decrease in
>> >>> cached filesystem data. Any suggestions? Thanks in advance!
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>> From: Dow_Hurst
>> >
>> >>>> Reply-To: Dow_Hurst
>> >
>> >>>> To: Ming
>> >
>> >>>> Subject: Re: namd-l: Memory keep increasing.
>> >>>> Date:Sat, 14 Nov 2009 02:10:51 -0500 (EST)
>> >>>>
>> >>>> I remember that XFS loves to cache data. Have you run sync on the
>> >>>> workstation during the run? And, measured any decrease in cached
>> >>>> filesystem data?
>> >>>> Dow
>> >>>>
>> >>>> -----Original Message-----
>> >>>>> From: Ming
>> >>>
>> >>>>> Sent: Nov 13, 2009 12:51 AM
>> >>>>> To: akohlmey_at_gmail.com
>> >>>>> Cc: namd-l_at_ks.uiuc.edu
>> >>>>> Subject: Re: namd-l: Memory keep increasing.
>> >>>>>
>> >>>>> Hi Axel,
>> >>>>> Thanks for your reply. I've been keeping moitering the memory
>> >>>>> changes. I found the memory still kept increasing while the job is
>> >>>>> runing. Below is the output of the "free -m -s 30". I'm sure
>> >>>>> nobody else uses this SGI Altix station. Is this increase in
>> >>>>> memory normal? Thanks!
>> >>>>>
>> >>>>> P.S.By the way, I found the used memory increased by 6G within 12
>> >>>>> hours.
>> >>>>>
>> >>>>> total used free shared buffers
>> >>>>> cached
>> >>>>> Mem: 61521 11543 49978 0
>> >>>>> 0 166
>> >>>>> -/+ buffers/cache: 11377 50144
>> >>>>> Swap: 9999 0 9999
>> >>>>>
>> >>>>> total used free shared buffers
>> >>>>> cached
>> >>>>> Mem: 61521 11553 49968 0
>> >>>>> 0 171
>> >>>>> -/+ buffers/cache: 11382 50139
>> >>>>> Swap: 9999 0 9999
>> >>>>>
>> >>>>> total used free shared buffers
>> >>>>> cached
>> >>>>> Mem: 61521 11555 49965 0
>> >>>>> 0 171
>> >>>>> -/+ buffers/cache: 11384 50137
>> >>>>> Swap: 9999 0 9999
>> >>>>>
>> >>>>> total us
>> >>
>>
>--
>Dr. Axel Kohlmeyer akohlmey_at_gmail.com
>Institute for Computational Molecular Science
>College of Science and Technology
>Temple University, Philadelphia PA, USA.
>
>

This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:51:42 CST