EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Question about displaying process memory allocation on Linux
From: Mark Rivers <[email protected]>
To: 'Jörn Dreyer' <[email protected]>, "[email protected]" <[email protected]>
Date: Tue, 26 Jun 2018 17:33:17 +0000
Hi  Jörn,

> Another way to check whats going on would be to run the IOC under valgrind using its leak checker. 
> That will report in the end how many memory was allocated and how many memory was given back correctly. 
> It also tells you to which memory you lost access during the run of your program.

I tried that.  The problem is that it is nearly 100 times slower running with valgrind, and that significantly changes the way the program operates.  Without valgrind the detector generates frames much faster than the plugins can process them, so the plugin consume memory in their queues.  With valgrind the detector is so slow the plugins seem to keep up, and the queues do not fill up.

However, valgrind did find a number of other issues that I need to track down!

Thanks,
Mark


-----Original Message-----
From: Jörn Dreyer <[email protected]> 
Sent: Tuesday, June 26, 2018 9:26 AM
To: [email protected]
Cc: Mark Rivers <[email protected]>
Subject: Re: Question about displaying process memory allocation on Linux

Dear Mark,

looking at the code in ellList.c of EPICS base 3.15.5, I see that the NDArray objects are not owned by the list. So the way to remove them, is to lock the list, retrieve the pointer to teh object, remove it from the list, delete the object and unlock the list.

I guess that's what you do. So in principal the memory should be given back also on Linux.
Another way to check whats going on would be to run the IOC under valgrind using its leak checker. That will report in the end how many memory was allocated and how many memory was given back correctly. It also tells you to which memory you lost access during the run of your program.

Regards,

Jörn

Am Dienstag, 26. Juni 2018, 15:51:32 CEST schrieb Mark Rivers:
> Folks,
> 
> In areaDetector the NDArrays are allocated from a free list in NDArrayPool. 
> Previously once a large number of arrays had been allocated on the 
> free list there was no way to free that memory back to the OS without 
> restarting the IOC.  I have now added an NDArrayPool::emptyFreeList() 
> method and an EmptyFreeList record that results in a call to that method.
> 
> When I test on Windows and I look at the Commit Size for the 
> simDetector process in Task Manager I see exactly what I expect.  If I 
> have large queues and the detector is acquiring faster than the plugins can process
> the free list contains NDArrays totaling over 3GB.   The Commit Size is
> ~3.2 GB.  When I process the EmptyFreeList record the CommitSize 
> immediately drops to 0.2 GB.
> 
> I am trying to see if I see the same thing on Linux, using the ps -o 
> trs,vsz,drs command.
> 
> This is what I see when I first start the simDetector IOC, before I 
> collect any images.  Note that the virtual memory size (VSZ) is 
> already 5GB.  This seems strange.  Can anyone explain?
> corvette:dxpSITORO/iocBoot/iocFalconX1>ps -p 115038 -o trs,vsz,drs TRS   
> VSZ   DRS
> 15838 5080984 5065145
> 
> This is what I see after collecting enough images that there is a 
> total of 3GB of NDArrays allocated.  VSZ has increased by 3GB (from 
> 5GB to 8GB), which is what I expect. corvette:dxpSITORO/iocBoot/iocFalconX1>ps -p 115038
> -o trs,vsz,drs TRS    VSZ   DRS
> 15838 8171424 8155585
> 
> This is what I see when acquisition has stopped and all plugins have 
> competed.  The NDArrays are now all on the free list, VSZ remains at 8 
> GB, which is what I expect. corvette:dxpSITORO/iocBoot/iocFalconX1>ps -p 115038
> -o trs,vsz,drs TRS    VSZ   DRS
> 15838 8171424 8155585
> 
> This is what I see after I process the EmptyFreeList record.  Note 
> that VSZ has only decreased by about 0.2GB, not by 3GB which I would have expected.
> Can anyone explain? corvette:dxpSITORO/iocBoot/iocFalconX1>ps -p 115038 -o
> trs,vsz,drs TRS    VSZ   DRS
> 15838 7974816 7958977
> 
> Is there another statistic I can look at to see that my process has 
> indeed returned all 3GB to the OS?
> 
> Thanks,
> Mark




References:
Question about displaying process memory allocation on Linux Mark Rivers
Re: Question about displaying process memory allocation on Linux Jörn Dreyer

Navigate by Date:
Prev: RE: Question about displaying process memory allocation on Linux Mark Engbretson
Next: Re: Question about RDB Channel archiver engine be used for the waveform channels Mazanec Tomáš
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Question about displaying process memory allocation on Linux Jörn Dreyer
Next: Re: Question about displaying process memory allocation on Linux J. Lewis Muir
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
ANJ, 27 Jun 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·