我想了解cf app命令报告的内存状态。 例如如果我的应用程序，它返回cf应用命令的CF内存使用情况
state since cpu memory disk details
这是什么意思2.2G真的？因为当我在newrelic中看到我的应用程序时，它显示正在使用〜1GB。我相信在应用程序启动时，实际分配也将取决于其他一些参数（xmx，内存calculatros？）。
（这是春天启动的应用程序）
它说，该应用程序的一个实例正在运行。该应用程序被分配/分配了4GB的内存（当您运行cf app时），该应用程序消耗了2.2 GB的内存。
如果New Relic报告的内存接近1 GB，那可能意味着还有其他内容占用了其他1.2 GB的内存。
我会先看看您正在使用的buildpack。您是使用标准的java buildpack还是您的公司创建的自定义buildpack？ buildpack是否添加了其他代理？像AppDynamics（不是说这是任何手段的罪魁祸首）或其他东西。找出并确定这些加载项消耗的内存量。
我会建议可能会做你的运行实例的heapdump。你将不得不ssh进入它的容器。磁头转储可能为2.2 GB，分配给您的应用程序的磁盘仅为1 GB，这会造成问题。有解决方案，但取决于您正在运行的PCF版本。
只是一个简单的问题，你有没有在你的应用中使用nashorn？
希望这会有所帮助！
运行cf app <app-name>时，输出显示Linux内核为您的容器报告的内存和CPU使用情况。 CF的最新版本使用Guardian & runc，使用Warden的旧版本获得此版本。
从概念上讲，您可以将其报告为容器内运行的所有进程的内存使用情况。这包括你的应用程序进程，同时也包含平台上的一些非常小的进程（一个是有助于cf ssh的SSH守护进程）。如果您想了解更多关于您的容器中运行的内容，我会建议执行cf ssh，然后查看ps aux或top。
关于您的特定应用程序，您看到的差异可能是由于它是Java应用程序。您需要确保您正在查看进程的全部内存使用情况，而不仅仅是堆使用情况。堆只是Java应用程序（包括PermGen（1.7）或Metaspace（1.8））的总内存使用量的一部分，JVM本身使用的线程，本地代码，直接内存和其他内存。
我们使用 - https://github.com/cloudfoundry/java-buildpack#v3.7 – user3444718
您使用的是标准buildpack。所以，那里没有插件。 您可以尝试ssh进入应用程序实例容器，并检查日志文件，看看是否有任何线索正在运行。 你必须做'heapdump'才能看起来很好。 你在什么版本的PCF？ –