CPU飙高，系统性能问题如何排查？

时间 2020-09-30 标签 cpu 系统性能问题如何排查

简介： 压测时或多或少都收到过CPU或者Load高的告警，若是是单机偶发性的，常常会认为是“宿主机抢占致使的”，那事实是否真是如此呢？是什么引发了这些指标的飙高？网络、磁盘仍是高并发？有什么工具能够定位？TOP、PS仍是vmstat？CPU高&Load高和CPU低&Load高，不一样的表征又表明着什么？html

一背景知识

LINUX进程状态

LINUX 2.6之后的内核中，进程通常存在7种基础状态：D-不可中断睡眠、R-可执行、S-可中断睡眠、T-暂停态、t-跟踪态、X-死亡态、Z-僵尸态，这几种状态在PS命令中有对应解释。linux

D (TASK_UNINTERRUPTIBLE)，不可中断睡眠态。顾名思义，位于这种状态的进程处于睡眠中，而且不容许被其余进程或中断(异步信号)打断。所以这种状态的进程，是没法使用kill -9杀死的(kill也是一种信号)，除非重启系统(没错，就是这么头硬)。不过这种状态通常由I/O等待(好比磁盘I/O、网络I/O、外设I/O等)引发，出现时间很是短暂，大多很难被PS或者TOP命令捕获(除非I/O HANG死)。SLEEP态进程不会占用任何CPU资源。
R (TASK_RUNNING)，可执行态。这种状态的进程都位于CPU的可执行队列中，正在运行或者正在等待运行，即不是在上班就是在上班的路上。
S (TASK_INTERRUPTIBLE)，可中断睡眠态。不一样于D，这种状态的进程虽然也处于睡眠中，可是是容许被中断的。这种进程通常在等待某事件的发生（好比socket链接、信号量等），而被挂起。一旦这些时间完成，进程将被唤醒转为R态。若是不在高负载时期，系统中大部分进程都处于S态。SLEEP态进程不会占用任何CPU资源。
T&t (__TASK_STOPPED & __TASK_TRACED)，暂停or跟踪态。这种两种状态的进程都处于运行中止的状态。不一样之处是暂停态通常因为收到SIGSTOP、SIGTSTP、SIGTTIN、SIGTTOUT四种信号被中止，而跟踪态是因为进程被另外一个进程跟踪引发(好比gdb断点）。暂停态进程会释放全部占用资源。
Z (EXIT_ZOMBIE), 僵尸态。这种状态的进程实际上已经结束了，可是父进程尚未回收它的资源（好比进程的描述符、PID等）。僵尸态进程会释放除进程入口以外的全部资源。
X (EXIT_DEAD), 死亡态。进程的真正结束态，这种状态通常在正常系统中捕获不到。

Load Average & CPU使用率

谈到系统性能，Load和CPU使用率是最直观的两个指标，那么这两个指标是怎么被计算出来的呢？是否能互相等价呢？ios

Load Average网络

很多人都认为，Load表明正在CPU上运行&等待运行的进程数，即并发

但Linux系统中，这种描述并不彻底准确。负载均衡

如下为Linux内核源码中Load Average计算方法，能够看出来，所以除了可执行态进程，不可中断睡眠态进程也会被一块儿归入计算，即：异步

602staticunsignedlongcount_active_tasks(void)
603 {
604structtask_struct*p;
605unsignedlongnr=0;
606607read_lock(&tasklist_lock);
608for_each_task(p) {
609if ((p->state==TASK_RUNNING610 (p->state&TASK_UNINTERRUPTIBLE)))
611nr+=FIXED_1;
612 }
613read_unlock(&tasklist_lock);
614returnnr;
615 }
......
625staticinlinevoidcalc_load(unsignedlongticks)
626 {
627unsignedlongactive_tasks; /* fixed-point */628staticintcount=LOAD_FREQ;
629630count-=ticks;
631if (count<0) {
632count+=LOAD_FREQ;
633active_tasks=count_active_tasks();
634CALC_LOAD(avenrun[0], EXP_1, active_tasks);
635CALC_LOAD(avenrun[1], EXP_5, active_tasks);
636CALC_LOAD(avenrun[2], EXP_15, active_tasks);
637 }
638 }

在前文 Linux进程状态中有提到过，不可中断睡眠态的进程(TASK_UNINTERRUTED)通常都在进行I/O等待，好比磁盘、网络或者其余外设等待。由此咱们能够看出，Load Average在Linux中体现的是总体系统负载，即CPU负载 + Disk负载 + 网络负载 + 其他外设负载，并不能彻底等同于CPU使用率(这种状况只出如今Linux中，其他系统好比Unix，Load仍是只表明CPU负载)。socket

CPU使用率tcp

CPU的时间分片通常可分为4大类：用户进程运行时间 - User Time, 系统内核运行时间 - System Time, 空闲时间 - Idle Time, 被抢占时间 - Steal Time。除了Idle Time外，其他时间CPU都处于工做运行状态。高并发

一般而言，咱们泛指的总体CPU使用率为User Time 和 Systime占比之和(例如tsar中CPU util)，即：

为了便于定位问题，大多数性能统计工具都将这4类时间片进一步细化成了8类，以下为TOP对CPU时间片的分类。

us：用户进程空间中未改变过优先级的进程占用CPU百分比
sy：内核空间占用CPU百分比
ni：用户进程空间内改变过优先级的进程占用CPU百分比
id：空闲时间百分比
wa：空闲&等待I/O的时间百分比
hi：硬中断时间百分比
si：软中断时间百分比
st：虚拟化时被其他VM窃取时间百分比

这8类分片中，除wa和id外，其他分片CPU都处于工做态。

二资源&瓶颈分析

从上文咱们了解到，Load Average和CPU使用率可被细分为不一样的子域指标，指向不一样的资源瓶颈。整体来讲，指标与资源瓶颈的对应关系基本以下图所示。

Load高 & CPU高

这是咱们最常遇到的一类状况，即load上涨是CPU负载上升致使。根据CPU具体资源分配表现，可分为如下几类：

CPU sys高

这种状况CPU主要开销在于系统内核，可进一步查看上下文切换状况。

若是非自愿上下文切换较多，说明CPU抢占较为激烈，大量进程因为时间片已到等缘由，被系统强制调度，进而发生的上下文切换。
若是自愿上下文切换较多，说明可能存在I/O、内存等系统资源瓶颈，大量进程没法获取所需资源，致使的上下文切换。

CPU si高

这种状况CPU大量消耗在软中断，可进一步查看软中断类型。通常而言，网络I/O或者线程调度引发软中断最为常见：

NET_TX & NET_RX。NET_TX是发送网络数据包的软中断，NET_RX是接收网络数据包的软中断，这两种类型的软中断较高时，系统存在网络I/O瓶颈可能性较大。
SCHED。SCHED为进程调度以及负载均衡引发的中断，这种中断出现较多时，系统存在较多进程切换，通常与非自愿上下文切换高同时出现，可能存在CPU瓶颈。

CPU us高

这种状况说明资源主要消耗在应用进程，可能引起的缘由有如下几类：

死循环或代码中存在CPU密集计算。这种状况多核CPU us会同时上涨。
内存问题，致使大量FULLGC，阻塞线程。这种状况通常只有一核CPU us上涨。
资源等待形成线程池满，连带引起CPU上涨。这种状况下，线程池满等异常会同时出现。

Load高 & CPU低

这种状况出现的根本缘由在于不可中断睡眠态(TASK_UNINTERRUPTIBLE)进程数较多，即CPU负载不高，但I/O负载较高。可进一步定位是磁盘I/O仍是网络I/O致使。

三排查策略

利用现有经常使用的工具，咱们经常使用的排查策略基本以下图所示：

从问题发现到最终定位，基本可分为四个阶段：

资源瓶颈定位

这一阶段经过全局性能检测工具，初步定位资源消耗异常位点。

经常使用的工具备：

top、vmstat、tsar(历史)
- 中断：/proc/softirqs、/proc/interrupts
- I/O：iostat、dstat

热点进程定位

定位到资源瓶颈后，可进一步分析具体进程资源消耗状况，找到热点进程。

经常使用工具备：

上下文切换：pidstat -w
CPU：pidstat -u
I/O：iotop、pidstat -d
僵尸进程：ps

线程&进程内部资源定位

找到具体进程后，可细化分析进程内部资源开销状况。

经常使用工具备：

上下文切换：pidstat -w -p [pid]
CPU：pidstat -u -p [pid]
I/O: lsof

热点事件&方法分析

获取到热点线程后，咱们可用trace或者dump工具，将线程反向关联，将问题范围定位到具体方法&堆栈。