其实原本是要帮某系统分析采用Tomcat作为应用服务的应用系统每隔两三天就出现内存溢出导致需要重启的问题，结果中途也发现该服务器的CPU长时间都保持在30%多，从进程上看，主要是Java进程一直长时间占用CPU资源不释放。
分析过程：
1. 该系统本来就一直存在因内存泄漏而导致的内存溢出(OOM)问题，可见应用程序上极有可能确实存在导致内存泄漏的不足之处。
2. 查看Tomcat的启动脚本，发现采用的是默认配置，初始分配的内存很小，最大可用内存非常有限。
3. 那么，应用程序将会出现一个什么样的情况呢？因为启动的时候采用的是最小化内存分配策略，不够的时候再继续跟操作系统申请。所以，随着应用启动后业务的不断接入，JVM势必需要不断地为应用申请新的内存空间，同时，根据JVM的管理策略，一般情况下只要堆空间使用率超过75%时会触发GC（垃圾回收）的操作。申请内存及垃圾回收操作都是两个比较耗费系统资源的操作，如果应用系统不停地在往操作系统申请内存，同时还因为堆空间使用过高而不断进行GC操作，那么应用层面自然会出现慢的情况，而操作系统层面自然就会出现CPU长时间保持较高使用率的情况（至于保持在多高，则看CPU的运算能力了）
处理方式：
经过检查服务器配置，该服务器的配置为64核CPU，256G内存，考虑到该应用其实目前还在试运行阶段，实际压力也并没有那么大，因此对Tomcat启动脚本进行如下配置：
1. 将启动最小、最大内存设置为16G，将最小、最大设置为一致，主要为了尽量避免频繁内存调整带来的开销。
2. 配置当发生内存溢出的情况时，将内存中的信息dump到本地的操作，以便下次内存溢出时分析问题的根本原因。
3. 给Tomcat配置Jconsole监控的配置，以便随时监控JVM的运行状况。
调整结果：
1. 经过一个下午的持续观察发现，CPU基本上大部分时间都保持在10%以下，暂时没有发现长时间保持30%多的情况发生。
2. 需要继续监控内存溢出的问题是否依然存在，如果只是因为未合理分配给JVM内存导致应用容易内存溢出，则本次调整即可解决问题；如果程序确实存在缺陷，则内存泄漏的问题将依旧存在，本次调整只是延长了发生内存溢出的间隔时间而已，到时候还需要继续分析dump文件来确定根本原因。
网友评论