透过现象看本质 CPU上下文切换

透过现象看本质 CPU上下文切换

写在前言

经常会看到看到cpu 使用率非常高的情况。在这种情况下，资源的使用监控分析才是性能故障分析的根本首要任务，通过这些分析，理解服务器如何运行，资源损耗在哪些方面对问题进行故障诊断是非常有价值有意义的。

经常会看到看到cpu 使用率非常高的情况。在这种情况下，资源的使用监控分析才是性能故障分析的根本首要任务，通过这些分析，理解服务器如何运行，资源损耗在哪些方面对问题进行故障诊断是非常有价值有意义的。

CPU的5种状态

在linux平台下cpu存在5种状态使用组合。

us:用户空间占用CPU百分比sy:内核空间占用CPU百分比ni:用户进程空间内改变过优先级的进程占用CPU百分比id:空闲CPU百分比wa: 等待输入输出的CPU时间百分比hi: 硬件中断si: 软件中断st: 实时

备注：从上述情况介绍来看，sy系统和ni&si软硬中断，基本系统自动控制，干涉部分不是太多.us，id，wa有一定的优化空间，有效的使用资源。

CPU上下文的切换

CPU上下文切换是保证 Linux系统正常工作的一个核心功能，按照不同场景，可以分为进程上下文切换、线程上下文切换和中断上下文切换。究竟怎么分析CPU上下文切换的问题。

过多的上下文切换，会把CPU时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上，缩短进程真正运行的时间，成了系统性能大幅下降的一个元凶。

既然上下文切换对系统性能影响那么大，到底要怎么査看上下文切换呢？可以使用vmstat这个工具，来查询系统的上下文切换情况。

vmstat是常用的系统性能分析工具，主要用来分析系统的内存使用情况，也常用来分析 CPU上下文切换和中断的次数。

[root@~]# vmstat 2procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 391648 2076 286040 0 0 69 52 70 66 1 1 99 0 0 0 0 0 391656 2076 286040 0 0 0 0 49 42 0 0 100 0 0 0 0 0 391656 2076 286040 0 0 0 0 44 38 0 0 100 0 0^C

​​procs​​（进程）

​​r​​：当前运行队列中线程的数目，代表线程处于可运行状态，但CPU还未能执行，这个值可以作为判断CPU是否繁忙的一个指标；当这个值超过了CPU数目，就会出现CPU瓶颈了；这个我们可以结合​​top​​命令的负载值同步评估系统性能（等待运行的进程数（(Running or Runnable)是就绪队列的长度，也就是正在运行和等待CPU的进程数））​​b​​：处在非中断睡眠状态的进程数

​​system​​（系统）这2个值越大，会看到由内核消耗的CPU时间会越大

​​in​​：(interrupt)则是每秒中断的次数，包括时钟中断​​cs​​： (context switch)是每秒上下文切换的次数

​​cpu​​（以百分比表示）

​​us​​：用户进程执行时间(user time)；​​sy​​：系统进程执行时间(system time)；​​id​​：空闲时间(包括IO等待时间)；​​wa​​：等待IO时间；wa的值高时，说明IO等待比较严重，这可能由于磁盘大量作随机访问造成，也有可能磁盘出现瓶颈。

r： 表示运行队列(就是说多少个进程真的分配到CPU)，我测试的服务器目前CPU比较空闲，没什么程序在跑，当这个值超过了CPU数目，就会出现CPU瓶颈了。这个也和top的负载有关系，一般负载超过了3就比较高，超过了5就高，超过了10就不正常了，服务器的状态很危险。top的负载类似每秒的运行队列。如果运行队列过大，表示你的CPU很繁忙，一般会造成CPU使用率很高。

cs：每秒上下文切换次数，例如我们调用系统函数，就要进行上下文切换，线程的切换，也要进程上下文切换，这个值要越小越好，太大了，要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中，我们一般做性能测试时会进行几千并发甚至几万并发的测试，选择web服务器的进程可以由进程或者线程的峰值一直下调，压测，直到cs到一个比较小的值，这个进程和线程数就是比较合适的值了。系统调用也是，每次调用系统函数，我们的代码就会进入内核空间，导致上下文切换，这个是很耗资源，也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换，导致CPU干正经事的时间少了，CPU没有充分利用，是不可取的。

vmstat只给出了系统总体的上下文切换情况，要想查看每个进程的详细情况，就需要使用pidstat 了。给它加上-w选项，你就可以查看每个进程上下文切换的情况了。

[root@~]# pidstat -w 5Linux 3.10.0-693.el7.x86_64 (lutixia.com) 07/02/2020 _x86_64_ (2 CPU)08:17:53 PM UID PID cswch/s nvcswch/s Command08:17:58 PM 0 3 0.40 0.00 ksoftirqd/008:17:58 PM 0 7 0.40 0.00 migration/008:17:58 PM 0 9 1.20 0.00 rcu_sched08:17:58 PM 0 10 0.20 0.00 watchdog/008:17:58 PM 0 11 0.20 0.00 watchdog/108:17:58 PM 0 12 0.20 0.00 migration/1

这个结果中有两列内容是我们的重点关注对象。

一个是cswch,表示每秒自愿上下文切换 (voluntary context switches)的次数，另一个则是nvcswch ,表示每秒非自愿上下文切换 (non voluntary context switches)的次数

所谓自愿上下文切换，是指进程无法获取所需资源，导致的上下文切换。比如说，I/O、内存等系统资源不足时，就会发生自愿上下文切换。而非自愿上下文切换，则是指进程由于时间片巳到等原因，被系统强制调度，进而发生的上下文切换。比如说，大量进程都在争抢CPU时，就容易发生非自愿上下文切换。

这两列如果数值比较大意味着不同的性能问题:

自愿上下文切换时说明进程在等待资源，有可能发生了I/O等问题非自愿上下文切换，说明进程在被强制调度，也就是在争抢CPU中断次数多了，说明CPU在被中断处理程序占用。可以通过/proc/interrupts 查看

透过现象看本质

环境准备

使用sysbench来模拟系统多线程调度切换的情况。

sysbench是一个多线程的基准测试工具，一般用来评估不同系统参数下的MySQL数据库库负载情况。这次案例中，我们只把它当成异常进程来看，作用是模拟上下文切换过多的问题。

下面的案例基于Centos 7.X,当然，其他的Linux系统同样适用。环境如下所示：

•机器配置：2 CPU, 1GB内存

•预先安装 sysbench 和 sysstat包，如 yum install epel* sysbench sysstat -y

操作开始前，你需要打开三个终端，登录到同一台Linux，并安装好上面两个软件包。安装完成后，你可以先用vmstat看一下空闲系统的上下文切次数：

[root@~]# vmstat 2 1procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st0 0 0 384484 2076 292804 0 0 31 25 46 41 0 0 99 0 0

可以看到上下文切换次数是cs 46，中断次数是25，r和b都是0因为系统比较空闲，没有运行比较繁忙的任务。

首先，在第一个终端里运行sysbench ,模拟系统多线程调度的瓶颈:

[root@~]# sysbench --threads=10 --max-time=300 threads runWARNING: --max-time is deprecated, use --time insteadsysbench 1.0.17 (using system LuaJIT 2.0.4)Running the test with following options:Number of threads: 10Initializing random number generator from current timeInitializing worker threads...Threads started!#PID为2的父亲进程[root@~]# ps -ef UID PID PPID C STIME TTY TIME CMDroot 1 0 0 20:02 ? 00:00:01 /usr/lib/systemd/systemd --switched-root --system --deserialize 21root 2 0 0 20:02 ? 00:00:00 [kthreadd]#可以看出PID为2的父亲进程生成了10个子线程[root@~]# ps -ef | grep kwor*root 5 2 0 20:02 ? 00:00:00 [kworker/0:0H]root 6 2 0 20:02 ? 00:00:00 [kworker/u256:0]root 15 2 0 20:02 ? 00:00:00 [kworker/1:0H]root 25 2 0 20:02 ? 00:00:04 [kworker/0:1]root 252 2 0 20:02 ? 00:00:00 [kworker/u256:2]root 507 2 0 20:02 ? 00:00:00 [kworker/u257:0]root 512 2 0 20:02 ? 00:00:00 [kworker/u257:1]root 778 2 0 20:02 ? 00:00:00 [kworker/1:1H]root 1068 2 0 20:02 ? 00:00:00 [kworker/0:1H]root 1213 2 0 20:37 ? 00:00:00 [kworker/1:2]root 1250 2 0 20:47 ? 00:00:00 [kworker/0:0]root 1252 2 0 20:48 ? 00:00:00 [kworker/1:1]root 1258 2 0 20:52 ? 00:00:00 [kworker/0:2]root 1273 2 0 20:55 ? 00:00:00 [kworker/1:0]

vmstat系统层面定位问题

接着，在第二个终端运行vmstat,观察上下文切换情况:

[root@~]# vmstat 1procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 9 0 0 381900 2076 293176 0 0 29 23 240 3698 0 2 98 0 0 7 0 0 381892 2076 293176 0 0 0 0 23350 1354895 7 91 3 0 0 8 0 0 381892 2076 293176 0 0 0 0 25311 1337914 7 91 2 0 0 6 0 0 381892 2076 293176 0 0 0 0 25632 1440565 8 91 2 0 0^C

你应该可以发现，CS列的上下文切换次数从之前的46骤然上升到了 130W+。同时，注意观察 其他几个指标：

• r列：就绪队列的长度已经到了 6+，远远超过了系统CPU的个数 2，所以肯定会有大量的 CPU竞争

• us (user)和sy (system)列：这两列的CPU使用率加起来上升到了100%(91+7 91+8 98+2),其中系统 CPU使用率，也就是sy列高达91%,说明CPU主要是被内核占用了

• in列中断次数也上升到了 2W+左右，说明中断处理也是个潜在的问题

综合这几个指标，我们可以知道，系统的就绪队列过长，也就是正在运行和等待CPU的进程数量过多，导致了大量的上下文切换，而上下文切换又导致了系统CPU的占用率升高。

pidstat具体定位vmstat产生的问题，缩小范围定位问题

那么到底是什么进程导致了这些问题呢？第三个终端再用pidstat来看一下，CPU和进程上下文切换的情况

[root@~]# uptime 22:08:21 up 2:05, 3 users, load average: 5.97, 2.90, 2.00#-w表示进程切换指标，-u表示CPU使用率[root@~]# pidstat -w -u 1Linux 3.10.0-693.el7.x86_64 (lutixia.com) 07/02/2020 _x86_64_ (2 CPU)08:54:57 PM UID PID %usr %system %guest %CPU CPU Command08:54:58 PM 0 689 0.00 0.96 0.00 0.96 1 vmtoolsd08:54:58 PM 0 1259 12.50 100.00 0.00 100.00 1 sysbench08:54:58 PM 0 1272 0.00 0.96 0.00 0.96 0 pidstat08:54:57 PM UID PID cswch/s nvcswch/s Command08:54:58 PM 0 3 1.92 0.00 ksoftirqd/008:54:58 PM 0 9 17.31 0.00 rcu_sched08:54:58 PM 0 25 0.96 0.00 kworker/0:108:54:58 PM 0 252 0.96 0.00 kworker/u256:208:54:58 PM 0 689 10.58 0.00 vmtoolsd08:54:58 PM 0 1068 0.96 0.00 kworker/0:1H08:54:58 PM 0 1213 1.92 0.00 kworker/1:2

从pidstat的输出你可以发现，CPU使用率的升高果然是sysbench导致的，它的CPU使用率已经达到了100%。但上下文切换则是来自其他进程，包括非自愿上下文切换频率最高的 pidstat,以及自愿上下文切换频率最高的内核线程kworker。

pidstat输出的上下文切换次数，加起来也就几百，比vmstat的130W+明显小了太多。这是怎么回事呢？难道是工具本身出了错吗？

Linux调度的基本单位实际上是线程，而我们的场景sysbench模拟的也是线程的调度问题，pidstat忽略了线程的数据，pidstat默认显示进程的指标数据，加上-t参数后，才会输出线程的指标。

[root@~]# pidstat -wt 1Linux 3.10.0-693.el7.x86_64 (lutixia.com) 07/02/2020 _x86_64_ (2 CPU)09:18:38 PM UID TGID TID cswch/s nvcswch/s Command09:18:39 PM 0 9 - 3.96 0.00 rcu_sched09:18:39 PM 0 - 9 3.96 0.00 |__rcu_sched09:18:39 PM 0 13 - 1.98 0.00 ksoftirqd/109:18:39 PM 0 - 13 1.98 0.00 |__ksoftirqd/109:18:39 PM 0 25 - 2.97 0.00 kworker/0:109:18:39 PM 0 - 25 2.97 0.00 |__kworker/0:109:18:39 PM 0 32 - 0.99 0.00 khugepaged09:18:39 PM 0 - 32 0.99 0.00 |__khugepaged09:18:39 PM 0 252 - 0.99 0.00 kworker/u256:209:18:39 PM 0 - 252 0.99 0.00 |__kworker/u256:209:18:39 PM 0 - 706 0.99 0.00 |__in:imjournal09:18:39 PM 0 689 - 9.90 0.00 vmtoolsd09:18:39 PM 0 - 689 9.90 0.00 |__vmtoolsd09:18:39 PM 0 - 1011 0.99 0.00 |__tuned09:18:39 PM 0 1341 - 1.98 0.00 kworker/1:209:18:39 PM 0 - 1341 1.98 0.00 |__kworker/1:209:18:39 PM 0 - 1343 20120.79 122291.09 |__sysbench09:18:39 PM 0 - 1344 13162.38 110521.78 |__sysbench09:18:39 PM 0 - 1345 26090.10 119710.89 |__sysbench09:18:39 PM 0 - 1346 23462.38 96952.48 |__sysbench09:18:39 PM 0 - 1347 16571.29 107426.73 |__sysbench09:18:39 PM 0 - 1348 22124.75 116013.86 |__sysbench09:18:39 PM 0 - 1349 20953.47 114319.80 |__sysbench09:18:39 PM 0 - 1350 21472.28 108875.25 |__sysbench09:18:39 PM 0 - 1351 17744.55 120934.65 |__sysbench09:18:39 PM 0 - 1352 15824.75 108979.21 |__sysbench09:18:39 PM 0 1354 - 0.99 0.00 kworker/0:009:18:39 PM 0 - 1354 0.99 0.00 |__kworker/0:009:18:39 PM 0 1355 - 0.99 0.00 pidstat09:18:39 PM 0 - 1355 0.99 0.00 |__pidstat

现在你就能看到了，虽然sysbench进程（也就是主线程）的上下文切换次数看起来并不多，但它的子线程的上下文切换次数却有很多。看来上下文切换罪魁祸首，还是过多的sysbench线程。

我们已经找到了上下文切换次数增多的根源,那是不是到这儿就可以结束了呢？

当然不是。不知道你还记不记得，前面在观察系统指标时，除了上下文切换频率骤然升高，还有一个指标也有很大的变化。是的，正是中断次数。中断次数也上升到了2W+，但到底是什么类型的中断上升了，现在还不清楚。

既然是中断，我们都知道，它只发生在内核态，而pidstat只是一个进程的性能分析工具，并不提供任何关于中断的详细信息，怎样才能知道中断发生的类型呢？

/proc/interrupts

没错，那就是从/proc/interrupts这个只读文件中读取。/proc实际上是Linux的一个虚拟文件系统，用于内核空间与用户空间之间的通信。/proc/interrupts就是这种通信机制的一部分， 提供了一个只读的中断使用情况。

在/proc目录下面，有两个与中断子系统相关的文件和子目录，它们是：

/proc/interrupts：文件/proc/irq：子目录

读取interrupts会依次显示irq编号，每个cpu对该irq的处理次数，中断控制器的名字，irq的名字，以及驱动程序注册该irq时使用的名字

我们在第三个终端里，Ctrl+C停止刚才的pidstat命令，然后运行下面的命令，观察中断 的变化情况：

# -d 参数表示高亮显示变化的区域$ watch -d cat /proc/interrupts CPU0 CPU1...RES: 2450431 5279697 Rescheduling interrupts...

观察一段时间，你可以发现，变化速度最快的是重调度中断(RES)，这个中断类型表示，唤醒空闲状态的CPU来调度新的任务运行。这是多处理器系统(SMP)中，调度器用来分散任务到不同CPU的机制，通常也被称为处理器间中断(Inter-Processor Interrupts, IPI)

所以，这里的中断升高还是因为过多任务的调度问题，跟前面上下文切换次数的分析结果是一致的。

通过这个案例，你应该也发现了多工具、多方面指标对比观测的好处。如果最开始时，我们只用 了 pidstat观测，这些很严重的上下文切换线程，压根儿就发现不了了。

每秒上下文切换多少次才算正常呢？

这数值其实軼于系统本身的CPU性能。如果系统的上下文切换次数比较稳定，那么从数百到一万以内，都应该算是正常的。但当上下文切换次数超过一万次，或者切换次数出现数量级的增长时，就很可能已经出现了性能问题。

这时，你还需要根据上下文切换的类型，再鞘体分析。比方说：

自愿上下文切换变多了，说明进程都在等待资源，有可能发生了 I/O 等其他问题非自愿上下文切换变多了，说明进程都在被强制调度，也就是都在争抢 CPU，说明 CPU 的确成了瓶颈中断次数变多了，说明 CPU 被中断处理程序占用，还需要通过查看 /proc/interrupts 文件来分析具体的中断类型。

小结

今天，我通过一个 sysbench 的案例，给你讲了上下文切换问题的分析思路。碰到上下文切换次数过多的问题时，我们可以借助 vmstat  、  pidstat 和 /proc/interrupts 等工具，来辅助排查性能问题的根源。

结合前两节，首先通过uptime查看系统负载，然后使用mpstat结合pidstat来初步判断到底是cpu计算量大还是进程争抢过大或者是io过多，接着使用vmstat分析切换次数，以及切换类型，来进一步判断到底是io过多导致问题还是进程争抢激烈导致问题。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。