 |
 |
Hi Dan: This what I did and observed: 1. "top" shows: top - 17:13:27 up 5:47, 3 users, load average: 0.20, 0.20, 0.18 Tasks: 162 total, 1 running, 161 sleeping, 0 stopped, 0 zombie Cpu(s): 0.5%us, 0.2%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st Mem: 6043464k total, 1395624k used, 4647840k free, 65388k buffers Swap: 2031608k total, 0k used, 2031608k free, 888544k cached 2. 'Analysis 1.15' started and "top" shows: top - 17:15:28 up 5:49, 4 users, load average: 0.17, 0.17, 0.17 Tasks: 165 total, 1 running, 164 sleeping, 0 stopped, 0 zombie Cpu(s): 1.2%us, 0.5%sy, 0.0%ni, 98.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 6043464k total, 1445344k used, 4598120k free, 65560k buffers Swap: 2031608k total, 0k used, 2031608k free, 888552k cached 3. CCPN project is loaded and "top" shows: top - 17:22:00 up 5:56, 4 users, load average: 0.37, 0.40, 0.26 Tasks: 165 total, 1 running, 164 sleeping, 0 stopped, 0 zombie Cpu(s): 1.2%us, 0.5%sy, 0.0%ni, 98.2%id, 0.0%wa, 0.1%hi, 0.0%si, 0.0%st Mem: 6043464k total, 2275608k used, 3767856k free, 66080k buffers Swap: 2031608k total, 0k used, 2031608k free, 890200k cached 4. The project is closed and "top" shows: top - 17:23:43 up 5:57, 4 users, load average: 0.13, 0.32, 0.25 Tasks: 165 total, 2 running, 163 sleeping, 0 stopped, 0 zombie Cpu(s): 0.7%us, 0.3%sy, 0.0%ni, 98.9%id, 0.0%wa, 0.1%hi, 0.0%si, 0.0%st Mem: 6043464k total, 2275000k used, 3768464k free, 66216k buffers Swap: 2031608k total, 0k used, 2031608k free, 890204k cached 5. The same project is again loaded and "top" shows: top - 17:27:39 up 6:01, 4 users, load average: 0.98, 0.58, 0.36 Tasks: 165 total, 1 running, 164 sleeping, 0 stopped, 0 zombie Cpu(s): 0.4%us, 0.2%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st Mem: 6043464k total, 2924140k used, 3119324k free, 66528k buffers Swap: 2031608k total, 0k used, 2031608k free, 890204k cached 6. The project is closed and "top" shows: top - 17:30:01 up 6:04, 4 users, load average: 0.14, 0.38, 0.31 Tasks: 165 total, 1 running, 164 sleeping, 0 stopped, 0 zombie Cpu(s): 0.3%us, 0.1%sy, 0.0%ni, 99.5%id, 0.0%wa, 0.1%hi, 0.0%si, 0.0%st Mem: 6043464k total, 2925524k used, 3117940k free, 66720k buffers Swap: 2031608k total, 0k used, 2031608k free, 890196k cached 7. 'Analysis 1.15' is quit and "top" shows: top - 17:31:13 up 6:05, 4 users, load average: 0.22, 0.34, 0.30 Tasks: 163 total, 1 running, 162 sleeping, 0 stopped, 0 zombie Cpu(s): 1.8%us, 0.2%sy, 0.0%ni, 97.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 6043464k total, 1398116k used, 4645348k free, 66816k buffers Swap: 2031608k total, 0k used, 2031608k free, 890200k cached Does it make any sense? Sorry if it's my mistake... Thank you, Vitaliy > Date: Mon, 29 Jun 2009 21:06:10 +0100 > From: [log in to unmask] > Subject: Re: memeory footprint (was: Re: a more recent version for Mac?) > To: [log in to unmask] > > Hello Vitaly, > > Memory is a very funny thing and is handled slightly differently by various > OS. I recall that you're using CentOS so that's good as Linux is (slightly) > simpler to understand! > > Analysis *should* free up memory allocated to hold spectra when that > spectra is deleted / projects are closed. > > > The data from all > > projects opened during the single Analysis session remain sitting in the > > RAM after the projects have been closed but Analysis is still running > > How are you measuring your RAM allocation? There are several ways to > measure RAM, some we should worry about and others that are less important. > > There's a great explanation here > http://www.mikeash.com/?page=pyblog/friday-qa-2009-06-19-mac-os-x-process-memory-statistics.html > which is more Mac based, but as Mac OSX is unix based it's pretty much the > same idea (just different names). > > I think what you might be seeing is the virtual memory usage. This is where > Analysis used this space once, it was cached to disk and then freed from > RAM memory - but still present on disk! This isn't dangerous, but can be > quite disturbing when it grows to several G! > > Could you post your RAM findings - the commands and the numbers that look > worrying, if we still have lots of data in resident memory it's important > to fix, but if it's in virtual memory it's nothing to worry about - and > indeed can't be fixed. > > Thanks, Dan