我正在运行一个JVM来支持ElasticSearch。 我仍在resize和调整，所以我把JVM的最大堆大小设置为ElasticSearch的默认值1GB。 将数据放入数据库之后，我发现JVM的进程在SIZE top输出中显示了50GB。 看来这实际上是在系统上造成性能问题; 其他进程在分配内存时遇到困难。
在询问ElasticSearch社区时，他们build议说“只是”文件系统caching。 根据我的经验，文件系统caching不会显示为特定进程使用的内存。 当然，他们可能一直在谈论操作系统的文件系统caching以外的东西，也许是JVM或ElasticSearch本身在操作系统之上做的事情。 但他们也表示，如果需要的话，它会被释放，似乎没有发生。
所以任何人都可以帮我弄清楚如何调整JVM，或者ElasticSearch本身，不要使用太多的RAM。
系统是具有72GB RAM的Solaris 10 x86。 JVM是“Java（TM）SE运行时环境（build 1.7.0_45-b18）”。
我非常肯定，您从ElasticSearch社区获得的答案与ZFS ARC（自适应replacecaching）有关。 这当然假定你的文件系统是ZFS？
在ZFS上ARC可能占用主机上所有可用的RAMless于1Gb。 因此，在ZFS主机上， top工具有时会显示您的物理RAM即使不是极限，也接近极限。 这是devise。 ARC会自动释放内存给需要内存的进程。 ARC使用什么内存算作内核内存，所以你不能在进程输出中看到它。
在我每天看的大多数Solaris系统中，物理RAM消耗约为90％。 这不是因为它们被利用得很好，而是ZFS为了自己的目的而抓取未使用的RAM。 不要为此感到惊慌。 由于ARC是内核的一部分，因此可以将内存释放到需要光速的进程中。 因此 – 尽pipe你可以 – 我通常没有看到限制ZFS ARC的大小。 最好让ZFS做好工作。
所以，如果我们谈论ZFS，那么是的，文件系统caching不会在单个进程中显示为内存消耗。 你需要执行如下所示的内容：
echo "::memstat" | mdb -k
揭示你的记忆是如何被使用的。 “Anon”这一行覆盖了您在例如prstat输出中看到的所有用户登陆进程。
另外要知道的是JVM如何在内存分配和内存释放方面的工作。 JVM从OS获取内存，因为它只需要JVM -Xmx命令行参数。 未解决的问题是，如果JVM不再需要它，将如何（如果曾经）将内存释放回操作系统？ 你会发现很难find关于这个主题的信息。 这似乎取决于使用哪个垃圾回收器。 由于很难获得有关此主题的精确信息（不知道为什么），所以最好的select是假定JVM 非常不愿意将内存释放回操作系统。 换句话说：如果你允许一个JVM进程来获取50GB的内存，那么你最好能够永久地承担这个工作，而不是假设这只是一个爆发。
因此，如果要限制ElasticSearch进程可以使用的内存量，则需要查看JVM命令行参数 ，特别是-Xmx选项。