Re: How to capture CF runtime container and application memory usage

Daniel Mikusa

If you're trying to get the memory usage for everything running in the
app's container, then `cf app` is your best bet. If you want to look at
specific things inside the container (cause there will be more than one
process running in an app container), you could use the other commands that
you mentioned.

One note about Java NMT, it does not account for all memory in the JVM's
process (notably missing are third party native code memory allocations and
JDK class libraries), so what it reports will always be less than the
actual usage.


On Sat, Apr 29, 2017 at 12:02 PM, Zhiyong Li <Zhiyong.Li(a)> wrote:

We have used four different commands to capture the memory usage for the
Springboot apps running in CF runtime including: jcmp, ps, cf app and pmap.
However, everyone seems report different values. Do you know which one is
accurate? Here are example outputs:

Running “cf apps” the memory usage is reported as 930.4M:

C:\Program Files\Cloud Foundry>cf app mtp-identities
Showing health and status for app mtp-identities in org stocf / space dev
as admin...

name: mtp-identities
requested state: started
instances: 1/1
usage: 2G x 1 instances
last uploaded: Thu 27 Apr 19:01:05 EDT 2017
stack: cflinuxfs2
buildpack: java_buildpack

state since cpu memory disk
#0 running 2017-04-27T23:02:13Z 0.2% 930.4M of 2G 186M of 2G

If I ssh into the container and run ‘ps’, the RSS size is reported as 939M:

vcap(a)dpgdg9915eg:~$ ps axo user,pid,cpu,rss,size,vsize,nlwp,cmd --sort
vcap 13 - 962008 5909184 6023768 58 /home/vcap/app/.java-
-Xmx384M -XX:MaxMetaspaceSize=128M -Xss256K -Xms384M -XX:MetaspaceSize=128M
-javaagent:/home/vcap/app/lib/aspectjweaver-1.8.9.jar -Dserver.port=8080 -Dconsul.token=tobeusedfordemosonlyclnt
-XX:NativeMemoryTracking=detail -verbose:class
-XX:MaxDirectMemorySize=10M -XX:ReservedCodeCacheSize=240M -cp
/home/vcap/app/. org.springframework.boot.loader.JarLauncher

While still in the container, running pmap for the process, the RSS is
reported as 944M, and the “dirty” column reports 921M:
Address Kbytes RSS Dirty Mode Mapping

total kB 6030924 966196 942984

None of this looks close to what is reported via the NMT (jcmp) totals
though (644M of committed):

2017-04-28T12:28:03.81-0400 [APP/0] OUT Total: reserved=1889246KB
+84548KB, committed=659678KB +137612KB

Join { to automatically receive all group messages.