1、引言

由于最近Online环境爆出好几个问题，

导致开会被各位BOSS连续的盘问，

反正不是站着灵魂拷问，也不是坐着喝茶水闲聊。

具体咋样，脑补一下。

这让我彻夜难眠，辗转反侧，夜不能寝，饭不能吃，都消瘦了好几两肉！！

遥想当年，小鱼我什么时候背过Online的锅。

这说来也巧了…

前晚这Ali的小姐姐又找我撩骚 ，哦不，是聊天。

可能是知道我最近辗转反侧；

又对我思念心切…

我岂能放过这个机会…

于是乎牺牲我的睡眠时间，与她夜夜长谈。

最后整理出这篇博文《如何排查Online出现的问题》。

做过市场调研的，或者参与过主流产品的核心人员，都会了解到，现在市面上的产品，没有谁敢说自己的产品就是0缺陷；

之所以没曝出来或者影响有限：

①无非这些功能，我们不常使用，或者不涉及/不影响到主流功能，就可以忽略不计了；

②或者是产品影响力太小，几乎没啥人使用；

但是，Online环境出现问题，我们还是需要积极应对的，

毕竟流量就是上帝嘛！

那，接下来，就跟着小鱼一起，看看Online环境出现问题分类及排查方式。

2、环境问题

2.1 磁盘空间不足

操作步骤及查看内容：

1、 执行df -h 从总体查看磁盘状态

在这里，我们一般就看挂载点为根目录的/的容量，

这里只用到的了 25%，距离瓶颈还有很大空间。

2、如果这里的太大了，我们就需要进一步查看，那个目录大。执行du -sh*，查看/路径下的各个文件和目录的大小。

3、如果已知道那个目录文件很大，想看具体的文件内容，

执行ls -lh命令，会更详细的输出各文件的大小

>>>如果想刺激有点的话，可以执行 du-h*，很Nice的。

2.2 CPU与内存使用频率过高

这也是小鱼的项目中遇到过的，当时都达到90%了。

真不知道，当时CPU经历了什么…

好了，言归正传。

操作步骤及查看内容：

1、上来就直接 top:

看看都有哪些信息

我们可以看到，这里不仅仅有CPU的信息，还有PID所占资源的情况。

 - VIRT：表示使用的虚拟内存数量；

 - RES：表示使用的物理内存数量；

 - SHR：表示使用的共享内存数量；

 - S：表示进程的状态；

 - %CPU：表示CPU使用率；

 - %MEM：表示内存的使用率；

 - TIME：表示累计CPU的使用时长；

 - COMMAND：表示启动进程使用的命令行，Java 程序的话，可以看看 JVM 启动参数，看是否配置得合理

2、如果想看Java进程的情况，我们可以这样做。

①执行jps命令找到对应的PID;

②然后再 top -p 19063，专门看看这个Java进程的情况；

③如果想看到线程的，那么直接 top -p 19063 -H；

注：

①通过VIRT、RES和SHR三者，可以从内存角度看该进程的资源占用情况。

②S下的值，知道三个就足够了：

 - S：表示睡眠；

 - D：表示不可中断睡眠；

 - R：表示运行。

3、单独分析内存

直接使用 free -h，

参数的含义：

 - total：内存总数；

 - used：已经使用内存数；

 - free：完全空闲内存；

 - shared：多个进程共享的内存；

 - buffers：用于块设备数据缓冲，记录文件系统 metadata（目录，权限，属性等）；

 - cached：用于文件内容的缓冲；

 - available：真正剩余的可被程序应用的内存数。

2.3 网络延迟

能出现网络延迟的，绝对是太正常不过了，

不信你问问某通，某信，

哪个没啥事不搞点网络故障啥的…

遇到问题，不要慌，先拿手机拍个照！

2.3.1 查看所有链接中的socket

查看所有连接中socket，

执行命令： netstat -a

2.3.2 查看所有tcp链接信息

查看所有tcp链接信息，

执行命令：netstat -tnpa

2.3.3 实时流量数据统计

虽然上面的两个命令很方便，

但是，针对小鱼我这种懒人来说，

查看实时流量，还是觉得不太直观，所以，

我就想到了这个超级命令：iftop -P，输入后，瞬间把牛皮癣给治愈了。

参数解析：

中间的 <= => 这两个左右箭头，表示的是流量的方向。

 - TX：发送流量；

 - RX：接收流量；

 - TOTAL：总流量；

 - Cumm：运行 iftop 到目前时间的总流量；

 - peak：流量峰值；

 - rates：分别表示过去 2s 10s 40s 的平均流量。

当然，这种网络延迟问题，更多的是交给运维大佬去解决，毕竟，在我们这花费半个小时得出的结论，在运维大佬哪里，2分钟就知道了。

3、程序问题

程序问题的排查，绝对是Ali小姐姐明目张胆的给我温暖，

所以，我在这里，要特别的感谢这位小姐姐。

当然，我也是牺牲了我的睡眠时间来陪她聊天，哦，是谈论工作…

毕竟…

3.1 Java程序问题分析

这部分主要分享小姐姐给我的温暖 ，例子。

内存罢工，触发的报警。

执行步骤及截图内容：

1、使用jmap -dump分析堆内存中的快照，未发现有大对象问题

2、使用 jmap -heap 查看堆内存设置与当前使用情况，堆内存设置的是 6G

Attaching to process ID 127, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.202-b08
 
using thread-local object allocation.
Parallel GC with 4 thread(s)
 
Heap Configuration:
   MinHeapFreeRatio         = 0
   MaxHeapFreeRatio         = 100
   MaxHeapSize              = 6442450944 (6144.0MB)
   NewSize                  = 2147483648 (2048.0MB)
   MaxNewSize               = 2147483648 (2048.0MB)
   OldSize                  = 4294967296 (4096.0MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)
 
Heap Usage:
PS Young Generation
Eden Space:
   capacity = 2117074944 (2019.0MB)
   used     = 1150960080 (1097.6410675048828MB)
   free     = 966114864 (921.3589324951172MB)
   54.36558036180698% used
From Space:
   capacity = 15204352 (14.5MB)
   used     = 13860864 (13.21875MB)
   free     = 1343488 (1.28125MB)
   91.16379310344827% used
To Space:
   capacity = 15204352 (14.5MB)
   used     = 0 (0.0MB)
   free     = 15204352 (14.5MB)
   0.0% used
PS Old Generation
   capacity = 4294967296 (4096.0MB)
   used     = 188289400 (179.56676483154297MB)
   free     = 4106677896 (3916.433235168457MB)
   4.383954219520092% used
 
23604 interned Strings occupying 2341024 bytes.

这个信息有点长，我截图有点费劲，索性就把内容copy出来了…

3、使用 jstack 查看 jvm 线程运行信息，

上传到 fastthread.io 网站，仔细一瞅，这线程不是多一点呢。

一个线程需要占用大约 1M 的空间吧，而且不是占用 jvm 的内存空间，而是会占用操作系统空闲的内存空间。

机器内存是 8G，堆内存占了 6G，线程数这么多快超过 2G 了，再加上操作系统里其他程序占用的内存，

内存告警很正常，甚至可能 OOM~ ~

所以，一方面我们可以减少线程数，

另一方面可以把堆内存配置得小一点，使得堆内存加上线程占用的操作系统内存，不要超过 8G。

4、本地无法debug的调试技巧

这里，主要就推荐阿里的arthas这款工具了。

推荐理由：大家都知道了，我就不说了

操作步骤，就简单说一下：

 - 先申请个线上机器的约等于root的权限；

 - 在机器上下载arthas工具；

            >>>>>下载地址：https://alibaba.github.io/arthas/arthas-boot.jar

 - 使用 watch 命令可以实时观察一个方法的入参和出参。

 - 使用 trace 命令可以跟踪某个方法的耗时，而且可以深入这个方法所调用的方法的各个耗时。

这两个功能，平时的调试，也够满足的了，

但是这款功能，确实很强大的，包含但不仅限于：

 - dashboard 全局监控；

 - thread 查看所有线程信息，包括状态和 CPU 使用率；

 - thread -b 甚至可以直接定位到死锁信息；

 - jad 命令进行反编译；

更多的功能，小鱼就不在这里说了，免得有人说我又打广告了…

关于arthas更多内容，详细阅读官网文档。

5、总结

说到这里，吊打面试官系列的Online环境问题排查，就差不多写到这里。

吊打面试官系列，会持续更新。

内容很劲爆，图片很给力。

当然，Online环境出现问题，不仅仅局限于小鱼举的这些例子。

例如：环境配置不同；版本部署代码遗漏等等。

鲁迅说过：如果一切事物都是完美的，那它一定是不完美的。

所以，遇到问题，发现问题，我们及时应对：
有些能规避的，在前期规避就好，
实在无法规避的，就让暴风雨来得更猛烈些吧！