前言：

在工作中我们经常遇到线上问题，那么线上问题该如何快速排查呢，有些问题你以前遇到，如果再遇到类似的问题，就能很快排查出导致问题的原因。但如果某个问题你是第一次遇到，心中可能会有点无从下手的感觉。这篇文章总结了，我之前遇到过的一些线上问题排查思路。

运行环境配置调优

用户资源限制检查

使用ulimit –a检查当前用户资源限制情况，如下：

当open files值很低，会影响生产环境的并发量，如果open files项值为默认值1024，需要调大，方法：

使用root账号登录，修改/etc/security/limits.conf文件，增加或修改（已存在）如下行：

修改完成后，重新登录，使用ulimit –a查看修改是否生效。

tomcat配置调优（应用程序服务器）

JVM参数配置

1. 首先检查tomcat所用的JRE是否是64位，步骤如下：

Step1 查看tomcat/bin/catalina.sh，检查tomcat是否指定JRE路径，如下：

若JAVA_HOME项被注释（以“#”开头），则说明使用系统默认的JRE；若未注释，则说明指定了JRE。

Step2 检查tomcat所用JRE是否是64位版本，使用java -version -d64命令检查，如下：

如上所示，则是64位JRE；

如上所示，则是32位JRE。

JRE位数不同，可分配的物理内存也不同，32位JRE可管理的内存不能超过4GB。

需要确认现网应用服务器上可以分配给DACS应用系统的内存有多大，检查方式：

2.将tomcat停止，查看可用内存大小：

需要确认现网应用服务器上可以分配给DACS应用系统的内存有多大，检查方式：

将tomcat停止，查看可用内存大小：

可用物理内存大小m1=free+cached，以截图中所示为例：m1=3052MB+1181MB=4233MB。

JVM堆内存分配方案：

取可用物理内存80%分配给tomcat，现网如果有内存告警监控，可适当调低该比例。现以80%为例：

分配给应用的内存m2=m1*80%=4233MB*80%=3386MB

则tomcat中jvm参数配置应为：

tomcat/bin/catalina.sh中JAVA_OPTS="-server -Xms3386m –Xmx3386m –Xmn1270m"

说明：

-server 指定JVM运行模式为server，生产环境必须指定为server模式；

-Xms JVM堆的初始尺寸，值应等于m2，即3386MB；

-Xmx JVM堆的最大尺寸，值应等于m2，即3386MB；

-Xmn JVM堆中年轻代的大小，值应等于m2*3/8，即1270MB。

说明：

若JRE为32位，则-Xmx的值不应超过4GB，建议统一配置成3GB，即配置如下：

JAVA_OPTS="-server -Xms3072m -Xmx3072m -Xmn1152m"

tomcat HTTP连接器线程数配置

tomcat/conf/server.xml中，HTTP连接器建议按如下配置：
    <Connector protocol="HTTP/1.1"  acceptCount="200" connectionTimeout="30000" disableUploadTimeout="true" port="8080" redirectPort="8445" 
         maxThreads="700" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" URIEncoding="GBK"/>

说明：tomcat连接器中maxThreads的值代表了最大并发量，不应超过750，当对并发要求很高时，应使用tomcat集群，例如要求最大并发1000，应启动2个tomcat，每个并发500。

OOM问题

OOM问题在生产环境中，一旦出现，一般会是非常严重的问题，服务可能会挂掉。

但是OOM问题有多种情况，不同的情况，出现问题的原因不一样。

堆内存OOM

服务器的日志一般会打印下面的内容：

java.lang.OutOfMemoryError: Java heap space

这种是出现最多的OOM问题。

在Java服务启动时，可以增加下面的参数：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=heapdump.hprof

在发生OOM时，程序会自动把当时的内存使用情况，dump保存到指定的文件。

然后使用MAT（Memory Analyzer Tool），或者使用JDK自带的 Java visualvm，来分析dump 文件，找出导致OOM 的代码 。

栈内存OOM

出现栈内存OOM问题的异常信息如下：

java.lang.OutOfMemoryError: unable to create new native thread

如果实际工作中，出现这个问题，一般是由于创建的线程太多，或者设置的单个线程占用内存空间太大导致的。

这个时候需要排查服务的线程数量。

推荐使用线程池，可以减少线程的创建，有效控制服务中的线程数量。

栈内存溢出

出现栈内存溢出问题的异常信息如下：

java.lang.StackOverflowError

该问题一般是由于业务代码中写的一些递归调用，递归的深度超过了JVM允许的最大深度，可能会出现栈内存溢出问题。

如果生产环境中，出现了这个问题，可以排查一下递归调用是否正常，有可能出现了无限递归的情况。

GC OOM

出现GC OOM问题时异常信息如下：

java.lang.OutOfMemoryError: GC overhead limit exceeded

GC OOM一般是由于JVM在GC时，对象过多，导致内存溢出，建议调整GC的策略。

在老代80%时就是开始GC，并且将-XX:SurvivorRatio（-XX:SurvivorRatio=8）和-XX:NewRatio（-XX:NewRatio=4）设置的更合理。

元空间OOM

出现元空间OOM问题时异常信息如下：

java.lang.OutOfMemoryError: Metaspace

JDK8之后使用Metaspace来代替永久代，Metaspace是方法区在HotSpot中的实现。

这个问题一般是由于加载到内存中的类太多，或者类的体积太大导致的。

如果生产环境中出现了这个问题，可以通过下面的命令修改元空间大小：

-XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m

总结

以上是问题排查的几个常出现的点，也是提供了一些日志查询和参数配置思路。方便定位和解决问题。