内存caching过高，将使用交换

服务器中Java应用程序的速度减慢的原因只受到我们的想象（有时由Providence）所限制。 内存贪婪进程是其中的一部分，它们造成的内存耗尽意味着交换，与磁盘的交互会导致性能下降。

但是，在这种情况下，内存使用情况不会显示交换的症状（请参阅@Sven的注释）。 基于应用程序的行为，更加合理的解释。

Java应用程序对内存configuration非常敏感（除其他外）。 程序员对于Java（以及几乎所有的现代语言）都非常满意，因为他们不需要调用免费函数来避免内存泄漏，就像垃圾收集器所做的那样。 但是垃圾收集器在进入时可以冻结应用程序。 有各种types的垃圾收集。 在新区域的作用较小，旧区域较差，全部最差。

一般来说（当然在这种情况下），有必要研究内存的变化，以优化其configuration。 无论如何，我们可以看到以下几点：

• 分配给应用程序的内存是服务器总空间的32 GB中的12 GB。
• 分配给新对象的空间是12 GB中的4 GB。 正如您在堆调整参数中所看到的，它意味着2的NewRatio，符合最佳实践。 无论如何，应该考虑增加这个值。

NewSize和MaxNewSize参数控制新一代的最小和最大尺寸。 通过设置这些参数来调整新一代的大小。 年轻一代越大，次要收集越less。 年轻一代相对于老一代的规模是由NewRatio控制的。 例如，设置-XX：NewRatio = 3意味着旧世代与年轻世代的比例为1：3，伊甸园和生存空间的总体规模将是堆的四分之一。

默认情况下，使用Java HotSpot Server JVM调用Application Server。 服务器JVM的默认NewRatio是2：旧一代占用堆的2/3，而新一代占1/3。 更大的新一代可以容纳更多短命的物品，减less对主要collections品缓慢的需求。 老一代还足够大，可以容纳很多长寿命的东西

无论如何，其他资源（线程，池，连接等）的使用不应该被解雇。

你没有解释你的系统速度太慢，在哪里（交互式用户？批处理？），只能识别一个性能计数器，内存。 这不会find你的问题。 有条不紊地收集响应时间和监测数据，并深入了解应用程序和操作系统如何工作。

Linux机器上的一个很好的起点是60,000毫秒的Linux性能分析 。 CPU，存储，networking，错误，当然还有内存。

 uptime dmesg | tail vmstat 1 mpstat -P ALL 1 pidstat 1 iostat -xz 1 free -m sar -n DEV 1 sar -n TCP,ETCP 1 top 

通过分析应用程序，您可以深入了解应用程序。 在火焰中给Java阅读（也恰好是Netflix科技博客）。 -XX:+PreserveFramePointer选项允许Java堆栈与OS分析相关联。