线上问题解决思路

常见问题解决思路

下面介绍一下处理一些常见的问题时，使用ZProflier和ZDebugger系统与使用传统工具在流程和思路上的一些区别。一个新上线的系统如果处理能力达不到我们的预期，或者一个老的系统处理速度突然下降了，抑或频繁抛出异常，这些都促使我们去思考系统存在性能问题该优化了，那我们通常会碰到的性能问题有OOM、CPU占用率高、Load高、频繁GC等。OOM的现象为Java进程直接退出，出错日志里可以看到OutOfMemoryError的异常。如果发现频繁的做MajorGC甚至是FullGC，一般也是OOM的前兆。解决此类问题的主要手段是分析heapdump。

JDK自带jmap工具，使用命令jmap-dump:live,format=b,file=heap.bin即可将Java进程的heap内存按照HPROFBinaryFormat的格式dump

 

图1ZProfiler

到名字为heap.bin的文件里。命令中的live参数，意味在dump之前会做一次FullGC，保证dump出来的对象都尽量是活的对象，减少heap.bin的大小，降低工具的分析时间。是否要设置这个参数要视具体问题，比如想知道old区到底为什么会增长这么快，都增加了些什么对象呢？这个时候你可能没必要去加live参数了，只要连续做两次heapdump，然后做一次内存对比，就知道这段时间内增加了哪些对象。但如果你想找出一些长时间不释放的对象，分析其根引用树是怎样的，这时加上live参数来dump就比较合理。

常用的heapdump分析工具是EclipseMemoryAnalyzerTool，简称MAT。这款工具功能很强大，但正由于它过于强大，因此给初学者带来的学习成本也比较高。其次它是一个客户端程序，需要安装在本地，因此它也受限于本地的机器性能，比如本机内存就4GB，而heap文件大小为8GB，这时MAT就无法完成分析工作了。因为MAT本身也是Java程序，它在分析大heap时会出现不断做GC，甚至fullgc等异常情况，导致分析没有结果。针对这些问题，我们的性能分析产品ZProfiler精减了部分不常用的功能，保证绝大部分用户使用上的简便性。另外ZProfiler是个Web系统，运行在一台服务器上，分析能力不再受限于开发人员的机器性能，而WebUI操作的方式也大大减轻了开发人员的工作量。

CPU高的问题需要分层来考虑，首先检查操作系统层面的一些原因，比如频繁的memorypaging，可能导致Java应用在内核态花费的时间较多。也可以使用perf top（linux命令）检查JVM内部比如JIT，GC线程的CPU使用情况。如果JIT线程使用的CPU较高，就需要看看codecache或者其他JIT相关参数是否设置合理；如果是gc线程，就需要进一步分析gclog，然后调整GC相关的参数等。

排除以上原因之后，基本可以确认是Java代码的问题，可以使用ZProfiler提供了HotMethodProfiling功能查看热点方法，这个后面有详细描述。

Load高意味着运行的线程或者运行队列里的线程比较多，此时可以通过线程dump进行排查。线程dump，可以使用JDK自带的工具jstack，执行命令jstack即可，会将进程的所有Java线程给dump出来。如果还想跟踪native的堆栈，需要增加-m参数。当拿到线程dump之后，按照线程状态进行归类【注：JVM里dump出来的线程日志，线程的状态并不是100%的准确，细节可以参考JVMBug：多个线程持有一把锁？】。对于同一个系统，Load高的机器RUNNABLE态的线程数目一定比Load低的机器多。我们可以通过threaddump来分析这些多出的线程都在干嘛，从而找到Load高的原因。

针对线程分析，ZProfiler不仅仅从状态粒度提供了分析，还从锁粒度以及热点栈粒度做了统计分析，ZProfiler可以帮助用户看到一把锁影响到了哪些线程，哪个线程持有这把锁，那些线程正在等待这把锁，对于线程数因为同步锁的问题突然大增基本可以通过ZProifiler的分析结果看出问题在哪里。同样的，对于某个方法在哪些线程里或者运行态的线程里正在栈上执行，ZProfiler也提供了统计，方便用户排查Load高等问题。

 

图2 ZDebugger 

GC频繁是Java程序最常见的问题之一，大多数情况下都是由于相关参数配置不合理导致的。HotSpotGC相关的设置参数比较多，要找到比较合理的参数设置，首先要对应用的内存情况有一个总体的了解：比如应用运行稳定后，LiveDataSize大概是多少，这个会影响到-Xmx/-Xms/-Xmn的设置大小【注：CharlieHunt/BinuJohn合写的JavaPerformance提供了很好的Guide】；运行过程中创建的对象temp对象和longlived对象的大概比率，这个会影响到heap老区新区的设置比例。

查看GC情况通常有两种方式，一种是打开gclog相关的参数，事后分析gclog；另外一种是实时获取GC信息，可以打开JMX接口通过相关的MXbean获取，或者通过jstat命令。

gclog分析是个苦差，因为gclog输出的信息非常多，但是很多时候我们需要关注的是长期的趋势和整体的统计信息，人工分析太耗时间。目前也有一些不错的gclog分析工具，比如GCViewer。ZProfiler除了做了和GCViewer类似的工作之外，前面谈到过，ZProfiler系统本身就是部署在金融云里的，这意味着用户可以非常方便地通过简单的WebUI操作把gclog直接复制到ZProfiler上来分析。另外，我们也正在开发一些更高级的一些功能，在gclog分析完成后，给用户一些直接的建议，比如是否GCPause的时间过长，设置的GC参数应该如何调整，GC花费的CPU时间是不是过长等。

实时获取GC信息方面，VisualVM的VisualGC插件做的不错，非常直观地显示出当前应用的GC情况，但是分析方面做的不够。ZProfiler同样使用MXBean的方式获取实时的GC信息，将更有价值和更具统计意义的信息展示出来。而对于云上难以复现、偶发性的问题，我们推荐使用在线调试平台ZDebugger对运行中的程序进行在线调试。在线调试的原则是方便用户简单快速地打开调试器，且不能影响应用的正常运行。基于此思路，ZDebugger设计为基于Jetty的Web服务器，用户使用浏览器即可发送调试命令。调试器使用JDWP协议通过网络与被调试的JVM后端连接，在不重启JVM的情况下动态打开JVM调试功能，JVM在不阻断应用运行的前提下即时抓取断点处的运行信息并将其返回。

转载自：http://www.csdn.net/article/2015-05-20/2824726-Java