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> 2025 | 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> 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: tune CSS Phoebus's memory usage |
From: | "Kasemir, Kay via Tech-talk" <tech-talk at aps.anl.gov> |
To: | "Xiao, Lingran" <xiaol at anl.gov>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Mon, 29 Jul 2024 18:21:09 +0000 |
I’d be concerned about memory leaks, but not memory usage in general. Java Virtual Machine Memory --------------------------- CS-Studio/Phoebus is a plain Java application, with memory managed by the JVM. See also
https://developers.redhat.com/articles/2021/09/09/how-jvm-uses-and-allocates-memory When you launch the applications, the JVM option `-Xmx` sets the maximum amount of memory that the JVM will use, and `-Xms` sets the initial amount. For example, ``` export JDK_JAVA_OPTIONS="-Xms500M -Xmx2G" java -jar product.jar ``` will start the JVM will 500MB of memory, and it will allocate up to 2GB. A tool like VisualVM (free,
https://visualvm.github.io) or JProfiler (very good but not free,
https://www.ej-technologies.com/products/jprofiler/overview.html) can be used to track memory usage over time. What you should see is a sawtooth-type pattern where the application uses more and more memory, maybe up to the `-Xmx` limit, then frees it. When you open several displays, the sawtooth pattern may ramp up more rapidly, and when you then close those displays, it should free memory and return to a slower/longer sawtooth pattern. If you find a scenario
where the memory keeps increasing until running out of memory, you may have spotted a memory leak that should should report, ideally with a reproducible recipe.
Linux Memory ------------ It can be confusing to compare memory usage as reported by the JVM with the memory usage reported by the Linux OS. Especially the "VIRT" virtual memory indicated in for example `top` may appear huge, but that tends to have no practical significance, see for example
https://stackoverflow.com/questions/561245/virtual-memory-usage-from-java-under-linux-too-much-memory-used, which also points to related discussions of the glibc `MALLOC_ARENA_MAX` setting. |