1. 分析服务发布时间
分析:在服务发布一段时间后,出现该问题,可以断定与服务发布相关。
通过ps命令,可以看到一个进程的启动时间。如果启动时间与cpu load飙升时间点符合,或服务发布后的几分钟内产生,可以判断是新服务启动导致。
ps -ef | grep [pid]
解决:分析新上线代码,进行处理
2. 排查系统进程数
分析:根据负载的定义,可以排查是否是系统进程数量过多导致。这是我们会用到vmstat命令。
vmstat 1 10 # 每一秒显示一次,显示10次
输出的指标可分为6类[1]。我们关注procs下的r指标,虚拟机或容器下运行进程个数。
其次我们通过top命令查看进程状态,如cpu、内容使用率。
解决:通过上述分析,发现问题后,看是否系统部署不合理,部署了过多服务。可考虑扩容或更配置更好的系统。
3. 排查进程状态
分析:linux下进程常见的5种状态说明如下[2]:
Running or Runnable (R
Uninterruptible Sleep (D
Interruptable Sleep (S
Stopped (T
Zombie (Z
状态转换如下图
这里看到运行后,由于请求资源,但又申请不到资源,如IO、内存,此时会转换到D状态,不可中断,直到等待到申请的资源。
这种情况下会导致load增加,所以我们需要排查D状态进程。我们使用top命令,在输出结果S这一列,即是进程状态列。如果出现D状态,我们就需要重点关注。
Tasks: 183 total, 1 running, 182 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.7 us, 1.1 sy, 0.0 ni, 97.1 id, 0.4 wa, 0.0 hi, 0.7 si, 0.0 st
MiB Mem : 3936.4 total, 1925.0 free, 850.6 used, 1160.8 buff/cache
MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 2834.2 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2237 bob 20 0 252252 81740 49204 S 2.3 2.0 0:09.37 Xorg
2519 bob 20 0 3428664 375256 125080 S 2.0 9.3 0:19.57 gnome-shell
2909 bob 20 0 966852 49944 37308 S 1.0 1.2 0:02.28 gnome-terminal-
1 root 20 0 103500 13312 8620 S 0.7 0.3 0:04.44 systemd
3588 bob 20 0 20600 3936 3380 R 0.3 0.1 0:00.01 top
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
解决:通过jmap、athas[3]等分析工具判断内存是否存在泄漏,随后优化代码解决问题。
4. 排查I/O利用率
分析:借助iostat命令,看io利用率
解决:如果是宿主机上其它虚拟机导致,可以考虑更换服务。如果是自身服务问题,例如疯狂写日志,则考虑修改自身代码。
参考
[1]vmstat命令,https://www.howtogeek.com/424334/how-to-use-the-vmstat-command-on-linux/
[2]linux进程状态,https://www.baeldung.com/linux/process-states
[3]arthas,https://arthas.aliyun.com/doc/