线上问题排查：服务器篇

通常我们会在线上发现一些内存占用或者CPU占用比较高的进程.
使用top指定，我们可以看到当前服务器占用CPU和内存较高的一些进程。
同时，我们可以通过load average查看当前服务器的压力，按我的经验来说，2以上的服务器性能已经比较差了，需要动手进行排查问题。

在找到对应问题进程时，我们可以通过top -H -p pid来查看对应进程中各线程使用CPU和内存较高的部分。

此时，通过jstack可以看到该进程中的所有堆栈信息。
如果要排查进程中对应线程的堆栈详情，可以通过jstack pid |grep 'nid'，其中nid为线程id通过printf '%x\n' pid所得。

通常，会比较关注WAITING和TIMED_WAITING的部分，BLOCKED就不用说了。可以通过jstack pid |grep "java.lang.Thread.State" | sort -nr | uniq -c来对整个进程的状态进行把控，如果WAITING特别多，则需要重点关注。

通常，一些监控也可以监控该指标来报告当前线上服务的稳定性与安全性。

通常，线上问题可以关注一些gc的问题，通过jstat -gc pid 5000我们可以每5秒查看一次当前进行的gc情况。可以看到各个分区的容量和使用量，以及YGC\FGC的一些情况。如果gc过于频繁，可以针对性的分析以及解决。

可以通过vmstat pid来查看进程上下文相关的问题，这个接触的比较少，可以后续再进行补充。
ps：还有磁盘问题等也可以后续进行关注。

内存问题，很多的时候会表现为OOM和StackOverflow。

1.Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
这个意思是没有足够的内存空间给线程分配java栈，基本上还是线程池代码写的有问题。之前，在部署初版dubbo-admin时，因为开始的时候，设置的内存过小，导致OOM，后来通过修改-Xss参数来控制单个栈内存大小，同时，放大整体栈内存大小。
此处可以通过stackSize控制某个线程的属性，也可以通过-Xss来控制全局的单个栈内存大小。
2.Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
通过jstack和jmap来定位代码中存在的问题，如果一切正常，则需要通过-Xmx的值来扩大内存。
3.Caused by: java.lang.OutOfMemoryError: Meta space
这个意思是元数据区的内存占用已经达到XX:MaxMetaspaceSize设置的最大值，排查思路和上面的一致，参数方面可以通过XX:MaxPermSize来进行调整
4.Exception in thread "main" java.lang.StackOverflowError
表示线程栈需要的内存大于Xss值，同样也是先进行排查，参数方面通过Xss来调整，但调整的太大可能又会引起OOM。

通常可以通过jstat查看对应的gc分代变化问题，但是在排查问题的时候，更方便的是在启动参数上加入-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps开启gc日志。

1.垃圾收集器
通常，建议使用-XX:+UseG1GC,G1垃圾收集器。
2.YGC过于频繁
一般都是周期小，对象多，可以先考虑设置-Xmn、-XX:SurivorRatio等参数设置来调整Eden区或者新生代的大小。如果正常的设置已经无法达到要求，则需要jmap对dump文件进行排查.
3.日志查验
以G1日志为例：
Root Scanning耗时长，就要注意线程数、跨代引用。
Object Copy则需要关注对象生存周期。
Ref Proc耗时长，就要注意引用相关的对象。