生产服务器变慢，分析排查方法

短命女 2023-10-05 09:33 66阅读 0赞

生产服务器变慢了，一般都是从这几点去分析：服务器整体情况， CPU 使用情况，内存，磁盘，磁盘 IO ，网络 IO。

一、服务器整体情况（top）

看服务器整体使用情况，一般都是 top 命令搞定

![format_png][]

我知道当你看到这张图的时候，肯定有点儿懵，特别是一个个的数字，这都是个啥？

第 1 行：系统时间、运行时间、登录终端数、系统负载（三个数值分别为1分钟、5分钟、15分钟内的平均值，数值越小意味着负载越低）

第 2 行：进程总数、运行中的进程数、睡眠中的进程数、停止的进程数、僵死的进程数。一般情况下，只要没有僵死的进程，就没啥大问题。

第 3 行：用户占用资源百分比、系统内核占用资源百分比、改变过优先级的进程资源百分比、空闲的资源百分比等。

第 4 行：物理内存总量、内存空闲量、内存使用量、作为内核缓存的内存量

第 5 行：虚拟内存总量、虚拟内存空闲量、虚拟内存使用量、已被提前加载的内存量

第 6 行里面主要看 PID 和 COMMAND 这两个参数，其中 PID 就是进程 ID ， COMMAND 就是执行的命令，能够看到比较靠前的两个进程都是 java 进程

在当前这个界面，按下数字键盘 1 能够看到各个 CPU 的详细利用率

![20200904100307500.png][]

查看cpu占用率高的线程

top -H -p 12193

二、CPU使用情况（vmstat）

想要了解 CPU 使用情况的话，常用的命令就是 vmstat 。

![format_png 1][]

一般 vmstat 工具的使用是通过两个数字参数来完成的，第一个参数是采样的时间间隔，单位是秒，第二个参数是采样的次数，这次的命令是：`vmstat -n 3 2` 意思就是隔 3 秒取样一次，一共取样 2 次

<table> 
 <tbody> 
 <tr> 
 <td> 类别 </td> 
 <td> 项目 </td> 
 <td> 含义 </td> 
 <td> 说明 </td> 
 </tr> 
 <tr> 
 <td> Procs（进程） </td> 
 <td> r </td> 
 <td> 等待执行的任务数 </td> 
 <td> 表示运行队列(就是说多少个进程真的分配到CPU)，当这个值超过了CPU数目，就会出现CPU瓶颈了。这个也和top的负载有关系，一般负载超过了3就比较高，超过了5就高，超过了10就不正常了，服务器的状态很危险。top的负载类似每秒的运行队列。如果运行队列过大，表示你的CPU很繁忙，一般会造成CPU使用率很高。 </td> 
 </tr> 
 <tr> 
 <td> B </td> 
 <td> 等待IO的进程数量 </td> 
 <td> 表示阻塞的进程 </td> 
 </tr> 
 <tr> 
 <td> Memory(内存) </td> 
 <td> swpd </td> 
 <td> 正在使用虚拟的内存大小，单位k </td> 
 <td> 虚拟内存已使用的大小，如果大于0，表示你的机器物理内存不足了，如果不是程序内存泄露的原因，那么你该升级内存了或者把耗内存的任务迁移到其他机器。 </td> 
 </tr> 
 <tr> 
 <td> free </td> 
 <td> 空闲内存大小 </td> 
 <td> 空闲的物理内存的大小，我的机器内存总共8G，剩余3415M。 </td> 
 </tr> 
 <tr> 
 <td> buff </td> 
 <td> 已用的buff大小，对块设备的读写进行缓冲 </td> 
 <td> Linux/Unix系统是用来存储，目录里面有什么内容，权限等的缓存，我本机大概占用300多M </td> 
 </tr> 
 <tr> 
 <td> cache </td> 
 <td> 已用的cache大小，文件系统的cache </td> 
 <td> &nbsp;cache直接用来记忆我们打开的文件,给文件做缓冲，我本机大概占用300多M(这里是Linux/Unix的聪明之处，把空闲的物理内存的一部分拿来做文件和目录的缓存，是为了提高 程序执行的性能，当程序使用内存时，buffer/cached会很快地被使用。) </td> 
 </tr> 
 <tr> 
 <td> inact </td> 
 <td> 非活跃内存大小，即被标明可回收的内存，区别于free和active </td> 
 <td> 具体含义见：概念补充（当使用-a选项时显示） </td> 
 </tr> 
 <tr> 
 <td> active </td> 
 <td> 活跃的内存大小 </td> 
 <td> 具体含义见：概念补充（当使用-a选项时显示） </td> 
 </tr> 
 <tr> 
 <td> Swap </td> 
 <td> si </td> 
 <td> 每秒从交换区写入内存的大小（单位：kb/s） </td> 
 <td> 每秒从磁盘读入虚拟内存的大小，如果这个值大于0，表示物理内存不够用或者内存泄露了，要查找耗内存进程解决掉。我的机器内存充裕，一切正常。 </td> 
 </tr> 
 <tr> 
 <td> so </td> 
 <td> 每秒从内存写到交换区的大小 </td> 
 <td> 每秒虚拟内存写入磁盘的大小，如果这个值大于0，同上。 </td> 
 </tr> 
 <tr> 
 <td> IO </td> 
 <td> bi </td> 
 <td> 每秒读取的块数（读磁盘） </td> 
 <td>块设备每秒接收的块数量，这里的块设备是指系统上所有的磁盘和其他块设备，默认块大小是1024byte，我本机上没什么IO操作，所以一直是0，但是我曾在处理拷贝大量数据(2-3T)的机器上看过可以达到140000/s，磁盘写入速度差不多140M每秒</td> 
 </tr> 
 <tr> 
 <td> bo </td> 
 <td> 每秒写入的块数（写磁盘） </td> 
 <td>块设备每秒发送的块数量，例如我们读取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO过于频繁，需要调整。日志打印过于频繁和大量可能发生bo大的情况</td> 
 </tr> 
 <tr> 
 <td> system </td> 
 <td> in </td> 
 <td> CPU每秒中断数，包括时钟中断 </td> 
 <td> 这两个值越大，会看到由内核消耗的cpu时间sy会越多 秒上下文切换次数，例如我们调用系统函数，就要进行上下文切换，线程的切换，也要进程上下文切换，这个值要越小越好，太大了，要考虑调低线程或者进程的数目。例如在apache和nginx这种web服务器中，我们一般做性能测试时会进行几千并发甚至几万并发的测试，选择web服务器的进程可以由进程或者线程的峰值一直下调，压测，直到cs到一个比较小的值，这个进程和线程数就是比较合适的值了。系统调用也是，每次调用系统函数，我们的代码就会进入内核空间，导致上下文切换，这个是很耗资源，也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换，导致CPU干正经事的时间少了，CPU没有充分利用，是不可取的。 </td> 
 </tr> 
 <tr> 
 <td> cs </td> 
 <td> 每秒上下文切换数 </td> 
 </tr> 
 <tr> 
 <td> CPU（以百分比表示） </td> 
 <td> us </td> 
 <td> 用户进程执行消耗cpu时间(user time) </td> 
 <td> us的值比较高时，说明用户进程消耗的cpu时间多，但是如果长期超过50%的使用，那么我们就该考虑优化程序算法或其他措施了 </td> 
 </tr> 
 <tr> 
 <td> sy </td> 
 <td> 系统进程消耗cpu时间(system time) </td> 
 <td> sys的值过高时，说明系统内核消耗的cpu资源多，例如是IO操作频繁。这个不是良性的表现，我们应该检查原因。这里us + sy的参考值为80%，如果us+sy 大于 80%说明可能存在CPU不足 </td> 
 </tr> 
 <tr> 
 <td> Id </td> 
 <td> 空闲时间(包括IO等待时间) </td> 
 <td> 一般来说 us+sy+id=100。一般我认为id是空闲CPU使用率，us是用户CPU使用率，sy是系统CPU使用率。 </td> 
 </tr> 
 <tr> 
 <td> wa </td> 
 <td> 等待IO时间 </td> 
 <td> wa过高时，说明io等待比较严重，这可能是由于磁盘大量随机访问造成的，也有可能是磁盘的带宽出现瓶颈。 </td> 
 </tr> 
 </tbody> 
</table>

其中主要关注 procs 和 cpu 这两个参数

procs ：

*  r ：运行和等待 CPU 时间片的进程数，一般来说整个系统的运行队列不要超过总核数的 2 倍，要不然系统压力太大了
 *  b : 等待资源的进程数，比如正在等待磁盘 IO ，网络 IO 这种

cpu ：

*  us ：用户进程消耗 CPU 时间百分比， us 值高的话，说明用户进程消耗 CPU 时间比较长，如果长期大于 50% 的话，那就说明程序还有需要优化的地方
 *  sy ：内核进程消耗的 CPU 时间百分比
 *  us + sy 参考值为 80% ，如果大于 80% 的话，说明可能存在 CPU 不足

三、内存情况（free）

查看内存情况用的就是 free ， 它主要有三个命令：`free` `free -g` `free -m` ，阿粉是推荐 `free -m` 为啥呢，咱们瞅瞅它们各自的运行结果就知道了

![format_png 2][]

其中：`free` 命令运行结果显示的非常不友好，看到 3880324 可以快速告诉我它是多大吗？`free -g` 这个命令四舍五入了，明明给的内存是 4G ，结果使用 `free -g` 一查看，竟然成了 3G ？excuse me ？如果线上环境出问题了，你说因为内存给的不够，运维说，这锅我可不背。

相对来说， `free -m` 是比较容易看，而且结果也是比较精确的

如果应用程序可用内存/系统物理内存大于 70% 的话，说明内存是充足的，没啥问题，但是如果小于 20% 的话，就要考虑增加内存了。

四、磁盘空间（df）

如果排查磁盘问题的话，首先要看的就是磁盘空间够不够，还记得阿粉在上家公司的时候，用的还是 svn 出现了一个很神奇的问题，就是哪里都不报错，就是提交不上代码，排查到最后是磁盘空间不够...

所以别问阿粉为啥排查磁盘问题时，第一就是看磁盘空间够不够！！！

查看磁盘空间就是 `df` 或者 `df -h` 这两个命令了

![format_png 3][]

五、磁盘IO（iostat）

说到磁盘 IO 相信你一定能够想到，在对数据库进行操作时，第一要考虑到的就是磁盘 IO 操作，因为相对来说，如果在某个时间段给磁盘进行大量的写入操作会造成程序等待时间长，导致客户端那边好久都没啥反应，用户体验就降低了吗

检查磁盘 IO 情况的命令就是 iostat ，如果你用的时候发现提示：`-bash: iostat: command not found` ，那是因为没有安装 sysstat ，安装一下就可以了：`yum install -y sysstat`

接下来运行命令：`iostat -xdk 3 2` ，和 `vmstat` 命令很像有没有~

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VsZWFub3J5c3M_size_16_color_FFFFFF_t_70][]

这么多指标咱们不需要都关注，只要看其中这几个就可以了：

*  rkB/s ：每秒读取数据量 kB ；
 *  wkB/s ：每秒写入数据量 kB ；
 *  svctm ：I/O 请求的平均服务时间，单位毫秒；
 *  **util ：一秒中有百分之几的时间用于 I/O 操作，如果接近 100% 说明磁盘带宽跑满了，这个时候就要优化程序或者增加磁盘了**

六、网络IO（sar）

网络 IO 的话，可以通过 `sar -n DEV 3 2` 这条命令来看，和上面的差不多，意思就是每隔 3 秒取样一次，一共取样 2 次。

其中：

*  IFACE ：LAN 接口
 *  rxpck/s ：每秒钟接收的数据包
 *  txpck/s ：每秒钟发送的数据包
 *  rxKB/s ：每秒接收的数据量，单位 KByte
 *  txKB/s ：每秒发出的数据量，单位 KByte
 *  rxcmp/s ：每秒钟接收的压缩数据包
 *  txcmp/s ：每秒钟发送的压缩数据包
 *  rxmcst/s：每秒钟接收的多播数据包

这种方式特别简单直观，对新手来说比较容易看到。

七、线程情况（jstack）

**程序出现假死，卡顿等情况，若以上几方面排查后没有发现异常可以查看一下是否是线程死锁或阻塞导致的。尤其在打印日志频繁的服务中容易出现。**

查看JVM线程快照的命令，线程快照是当前JVM线程正在执行的方法堆栈集合。使用jstack命令可以定位线程出现长时间卡顿的原因，例如死锁，死循环等。jstack还可以查看程序崩溃时生成的core文件中的stack信息。

1、jstack用法：

/opt/java8/bin/jstack
 
 Usage:
 jstack [-l] <pid>
 (to connect to running process) 连接活动线程
 jstack -F [-m] [-l] <pid>
 (to connect to a hung process) 连接阻塞线程
 jstack [-m] [-l] <executable> <core>
 (to connect to a core file) 连接dump的文件
 jstack [-m] [-l] [server_id@]<remote server IP or hostname>
 (to connect to a remote debug server) 连接远程服务器
 
 Options:
 -F to force a thread dump. Use when jstack <pid> does not respond (process is hung)
 -m to print both java and native frames (mixed mode)
 -l long listing. Prints additional information about locks
 -h or -help to print this help message

2、常用命令

显示线程快照及锁信息

jstack -l pid值 | more

统计线程数

jstack -l pid值 | grep 'java.lang.Thread.State' | wc -l

定位CPU占用线程

jstack PID值|grep nid十六进制值 -A 30

举例如下：

（1）获取nid值

top -H -p 17850
    
    top - 17:43:15 up 5 days,  7:31,  1 user,  load average: 0.99, 0.97, 0.91
    Tasks:  32 total,   1 running,  31 sleeping,   0 stopped,   0 zombie
    Cpu(s):  3.7%us,  8.9%sy,  0.0%ni, 87.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
    Mem:  16333644k total,  9592504k used,  6741140k free,   165700k buffers
    Swap:        0k total,        0k used,        0k free,  6781620k cached
    
      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    17880 root      20   0 7588m 112m  11m R 99.9  0.7  50:47.43 java
    17856 root      20   0 7588m 112m  11m S  0.3  0.7   0:02.08 java
    17850 root      20   0 7588m 112m  11m S  0.0  0.7   0:00.00 java
    17851 root      20   0 7588m 112m  11m S  0.0  0.7   0:00.23 java
    17852 root      20   0 7588m 112m  11m S  0.0  0.7   0:02.09 java
    17853 root      20   0 7588m 112m  11m S  0.0  0.7   0:02.12 java
    17854 root      20   0 7588m 112m  11m S  0.0  0.7   0:02.07 java

（2）转化十六进制nid的命令

printf "%x\n" 17880          
    45d8

（3）jstack定位CPU高占用率的线程

jstack 17850|grep 45d8 -A 30
 "pool-1-thread-11" #20 prio=5 os_prio=0 tid=0x00007fc860352800 nid=0x45d8 runnable [0x00007fc8417d2000]
 java.lang.Thread.State: RUNNABLE
 at java.io.FileOutputStream.writeBytes(Native Method)
 at java.io.FileOutputStream.write(FileOutputStream.java:326)
 at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
 at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
 - locked <0x00000006c6c2e708> (a java.io.BufferedOutputStream)
 at java.io.PrintStream.write(PrintStream.java:482)
 - locked <0x00000006c6c10178> (a java.io.PrintStream)
 at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
 at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
 at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
 - locked <0x00000006c6c26620> (a java.io.OutputStreamWriter)
 at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
 at java.io.PrintStream.write(PrintStream.java:527)
 - eliminated <0x00000006c6c10178> (a java.io.PrintStream)
 at java.io.PrintStream.print(PrintStream.java:597)
 at java.io.PrintStream.println(PrintStream.java:736)
 - locked <0x00000006c6c10178> (a java.io.PrintStream)
 at com.demo.guava.HardTask.call(HardTask.java:18)
 at com.demo.guava.HardTask.call(HardTask.java:9)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
 at java.lang.Thread.run(Thread.java:745)
 
 "pool-1-thread-10" #19 prio=5 os_prio=0 tid=0x00007fc860345000 nid=0x45d7 waiting on condition [0x00007fc8418d3000]
 java.lang.Thread.State: WAITING (parking)
 at sun.misc.Unsafe.park(Native Method)
 - parking to wait for <0x00000006c6c14178> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9sYUVtaWJIRnhGdzRMZzlCdVRkeWpUSzl5U29Ka25KRDJVYnVWNTJicWlhMVVROWFLdVBVOUw3OXBZZ0dmbmJROFpzNDBpYUZMaWNROVU3MjMxZEZFRTRKS1EvNjQw?x-oss-process=image/format,png
[20200904100307500.png]: https://img-blog.csdnimg.cn/20200904100307500.png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9sYUVtaWJIRnhGdzRMZzlCdVRkeWpUSzl5U29Ka25KRDJjNTM3b0l0eHFTNklnaWFocnhsSmcyNnVLMXR2czV3dlFjYzJ4RXlrcHp3Z2VMVVlUeGVhUGpRLzY0MA?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9sYUVtaWJIRnhGdzRMZzlCdVRkeWpUSzl5U29Ka25KRDJpYVRpYnBtOWljVE9NbzR5cVRVMHZqem1DdkRKekNGUlVWYlpOMHR2eUlxVWliaWNVTG84RERSQ0Z6dy82NDA?x-oss-process=image/format,png
[format_png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9sYUVtaWJIRnhGdzRMZzlCdVRkeWpUSzl5U29Ka25KRDJsM2ljNXZJT1A3RlVDQzdtMmRQZVdnNnd2YlJ4SWZvUEY3aWNYcDF1V2lhTnBoT0FTa2liZEd2RmZBLzY0MA?x-oss-process=image/format,png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VsZWFub3J5c3M_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200904101003399.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VsZWFub3J5c3M=,size_16,color_FFFFFF,t_70