1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 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 <2018> 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Question about displaying process memory allocation on Linux |
From: | Mark Engbretson <[email protected]> |
To: | 'Mark Rivers' <[email protected]>, <[email protected]> |
Date: | Tue, 26 Jun 2018 09:03:20 -0500 |
Not an answer to your Linux issues . . . sorry . . . . but do you have a suggested place where you might suggest putting NDArrayPool::emptyFreeList() so that memory will always be flushed, when it can be? And perhaps a place where it can be done automagically when memory is about to be exceeded so that AD just starts to dump frames instead of crashing because there is no free memory left? From: [email protected] <[email protected]> On Behalf Of 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 |