4CPU性能排查总结1CPU使用率的计算Linux 作为一个多任务操作系统将每个 CPU 的时间划分为很短的时间片再通过调度器轮流分配给各个任务使用因此造成多任务同时运行的错觉节拍率Linux 通过事先定义的节拍率内核中表示为 HZ触发时间中断并使用全局变量 Jiffies 记录了开机以来的节拍数。每发生一次时间中断Jiffies 的值就加 1。节拍率 HZ 是内核的可配选项可以设置为 100、250、1000 等。不同的系统可能设置不同数值#节拍率设置成了 250也就是每秒钟触发 250 次时间中断。 $ grep CONFIG_HZ /boot/config-$(uname -r) CONFIG_HZ250正因为节拍率 HZ 是内核选项所以用户空间程序并不能直接访问。为了方便用户空间程序内核还提供了一个用户空间节拍率 USER_HZ它总是固定为 100也就是 1/100 秒。这样用户空间程序并不需要关心内核中 HZ 被设置成了多少因为它看到的总是固定值 USER_HZ。当用户空间程序请求时间信息例如读取/proc/stat或使用times()系统调用时内核会在内部进行换算/proc/stat 提供的就是系统的 CPU 和任务统计信息# 只保留各个CPU的数据 $ cat /proc/stat | grep ^cpu cpu 280580 7407 286084 172900810 83602 0 583 0 0 0 cpu0 144745 4181 176701 86423902 52076 0 301 0 0 0 cpu1 135834 3226 109383 86476907 31525 0 282 0 0 0第一行没有编号的 cpu 表示的是所有 CPU 的累加。其他列则表示不同场景下 CPU 的累加节拍数它的单位是 USER_HZ也就是 10 ms1/100 秒所以这其实就是不同场景下的 CPU 时间。CPU 使用率相关的重要指标user通常缩写为 us代表用户态 CPU 时间。注意它不包括下面的 nice 时间但包括了 guest 时间。nice通常缩写为 ni代表低优先级用户态 CPU 时间也就是进程的 nice 值被调整为 1-19 之间时的 CPU 时间。这里注意nice 可取值范围是 -20 到 19数值越大优先级反而越低。system通常缩写为 sys代表内核态 CPU 时间。idle通常缩写为 id代表空闲时间。注意它不包括等待 I/O 的时间iowait。iowait通常缩写为 wa代表等待 I/O 的 CPU 时间。irq通常缩写为 hi代表处理硬中断的 CPU 时间。softirq通常缩写为 si代表处理软中断的 CPU 时间。steal通常缩写为 st代表当系统运行在虚拟机中的时候被其他虚拟机占用的 CPU 时间。guest通常缩写为 guest代表通过虚拟化运行其他操作系统的时间也就是运行虚拟机的 CPU 时间。guest_nice通常缩写为 gnice代表以低优先级运行虚拟机的时间。CPU 使用率就是除了空闲时间外的其他时间占总 CPU 时间的百分比事实上为了计算 CPU 使用率性能工具一般都会取间隔一段时间比如 3 秒的两次值作差后再计算出这段时间内的平均 CPU 使用率即这个公式就是我们用各种性能工具所看到的 CPU 使用率的实际计算方法。/proc/[pid]/stat 也给每个进程提供了运行情况的统计信息查 man proc 可以查看每个指标含义性能分析工具给出的都是间隔一段时间的平均 CPU 使用率所以要注意间隔时间的设置对比一下 top 和 ps 这两个工具报告的 CPU 使用率默认的结果很可能不一样因为 top 默认使用 3 秒时间间隔而 ps 使用的却是进程的整个生命周期。2怎么查看 CPU 使用率top 显示了系统总体的 CPU 和内存使用情况以及各个进程的资源使用情况top 并没有细分进程的用户态 CPU 和内核态 CPUps 则只显示了每个进程的资源使用情况。pidstat 是专门分析每个进程 CPU 使用情况的工具。top命令# 默认每3秒刷新一次 $ top top - 11:58:59 up 9 days, 22:47, 1 user, load average: 0.03, 0.02, 0.00 Tasks: 123 total, 1 running, 72 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.3 us, 0.3 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 8169348 total, 5606884 free, 334640 used, 2227824 buff/cache KiB Swap: 0 total, 0 free, 0 used. 7497908 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 1 root 20 0 78088 9288 6696 S 0.0 0.1 0:16.83 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.05 kthreadd 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H ...这个输出结果中第三行 %Cpu 就是系统的 CPU 使用率按下数字 1 就可以切换到每个 CPU 的使用率了。每个进程都有一个 %CPU 列表示进程的 CPU 使用率。它是用户态和内核态 CPU 使用率的总和包括进程用户空间使用的 CPU、通过系统调用执行的内核空间 CPU 、以及在就绪队列等待运行的 CPU。在虚拟化环境中它还包括了运行虚拟机占用的 CPU。pidstat 命令就间隔 1 秒展示了进程的 5 组 CPU 使用率包括用户态 CPU 使用率 %usr内核态 CPU 使用率%system运行虚拟机 CPU 使用率%guest等待 CPU 使用率%wait以及总的 CPU 使用率%CPU。最后的 Average 部分还计算了 5 组数据的平均值。# 每隔1秒输出一组数据共输出5组 $ pidstat 1 5 15:56:02 UID PID %usr %system %guest %wait %CPU CPU Command 15:56:03 0 15006 0.00 0.99 0.00 0.00 0.99 1 dockerd ... Average: UID PID %usr %system %guest %wait %CPU CPU Command Average: 0 15006 0.00 0.99 0.00 0.00 0.99 - dockerd3进程的状态$ top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 28961 root 20 0 43816 3148 4040 R 3.2 0.0 0:00.01 top 620 root 20 0 37280 33676 908 D 0.3 0.4 0:00.01 app 1 root 20 0 160072 9416 6752 S 0.0 0.1 0:37.64 systemd 1896 root 20 0 0 0 0 Z 0.0 0.0 0:00.00 devapp 2 root 20 0 0 0 0 S 0.0 0.0 0:00.10 kthreadd 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq 7 root 20 0 0 0 0 S 0.0 0.0 0:06.37 ksoftirqd/0R 是 Running 或 Runnable 的缩写表示进程在 CPU 的就绪队列中正在运行或者正在等待运行。D 是 Disk Sleep 的缩写也就是不可中断状态睡眠Uninterruptible Sleep一般表示进程正在跟硬件交互并且交互过程不允许被其他进程或中断打断。Z 是 Zombie 的缩写僵尸进程也就是进程实际上已经结束了但是父进程还没有回收它的资源比如进程的描述符、PID 等。S 是 Interruptible Sleep 的缩写也就是可中断状态睡眠表示进程因为等待某个事件而被系统挂起。当进程等待的事件发生时它会被唤醒并进入 R 状态。I 是 Idle 的缩写也就是空闲状态用在不可中断睡眠的内核线程上。前面说了硬件交互导致的不可中断进程用 D 表示但对某些内核线程来说它们有可能实际上并没有任何负载用 Idle 正是为了区分这种情况。要注意D 状态的进程会导致平均负载升高 I 状态的进程却不会。T 或者 t也就是 Stopped 或 Traced 的缩写表示进程处于暂停或者跟踪状态。向一个进程发送 SIGSTOP 信号它就会因响应这个信号变成暂停状态Stopped再向它发送 SIGCONT 信号进程又会恢复运行如果进程是终端里直接启动的则需要你用 fg 命令恢复到前台运行。而当你用调试器如 gdb调试一个进程时在使用断点中断进程后进程就会变成跟踪状态这其实也是一种特殊的暂停状态只不过你可以用调试器来跟踪并按需要控制进程的运行。X也就是 Dead 的缩写表示进程已经消亡所以你不会在 top 或者 ps 命令中看到它。僵尸进程这是多进程应用很容易碰到的问题。正常情况下当一个进程创建了子进程后它应该通过系统调用 wait() 或者 waitpid() 等待子进程结束回收子进程的资源而子进程在结束时会向它的父进程发送 SIGCHLD 信号所以父进程还可以注册 SIGCHLD 信号的处理函数异步回收资源。如果父进程没这么做或是子进程执行太快父进程还没来得及处理子进程状态子进程就已经提前退出那这时的子进程就会变成僵尸进程。通常僵尸进程持续的时间都比较短在父进程回收它的资源后就会消亡或者在父进程退出后由 init 进程回收后也会消亡。一旦父进程没有处理子进程的终止还一直保持运行状态那么子进程就会一直处于僵尸状态。大量的僵尸进程会用尽 PID 进程号导致新进程不能创建$ ps aux | grep /app root 4009 0.0 0.0 4376 1008 pts/0 Ss 05:51 0:00 /app root 4287 0.6 0.4 37280 33660 pts/0 D 05:54 0:00 /app root 4288 0.6 0.4 37280 33668 pts/0 D 05:54 0:00 /appS 表示可中断睡眠状态D 表示不可中断睡眠状态s 表示这个进程是一个会话的领导进程而 表示前台进程组。进程组表示一组相互关联的进程比如每个子进程都是父进程所在组的成员而会话是指共享同一个控制终端的一个或多个进程组。比如我们通过 SSH 登录服务器就会打开一个控制终端TTY这个控制终端就对应一个会话。而我们在终端中运行的命令以及它们的子进程就构成了一个个的进程组其中在后台运行的命令构成后台进程组在前台运行的命令构成前台进程组。4Linux软中断(1)中断中断是系统用来响应硬件设备请求的一种机制它会打断进程的正常调度和执行然后调用内核中的中断处理程序来响应设备的请求。(如果在订外卖的时候你就跟配送员约定好让他送到后给你打个电话那你就不用苦苦等待了就可以去忙别的事情直到电话一响接电话、取外卖就可以了.“打电话”其实就是一个中断)中断其实是一种异步的事件处理机制可以提高系统的并发处理能力.为了减少对正常进程运行调度的影响中断处理程序就需要尽可能快地运行。中断处理程序在响应中断时还会临时关闭中断。这就会导致上一次中断处理完成之前其他中断都不能响应也就是说中断有可能会丢失。2个外卖第一份外卖送到时配送员给你打了个长长的电话。因为电话占线也就是关闭了中断响应第二个配送员的电话是打不通的。(2)软中断为了解决中断处理程序执行过长和中断丢失的问题Linux 将中断处理过程分成了两个阶段也就是上半部和下半部上半部用来快速处理中断它在中断禁止模式下运行主要处理跟硬件紧密相关的或时间敏感的工作。下半部用来延迟处理上半部未完成的工作通常以内核线程的方式运行。第一个配送员不会占用你太多时间当第二个配送员过来时照样能正常打通你的电话。网卡接收到数据包后会通过硬件中断的方式通知内核有新的数据到了。这时内核就应该调用中断处理程序来响应它上半部来说既然是快速处理其实就是要把网卡的数据读到内存中然后更新一下硬件寄存器的状态表示数据已经读好了最后再发送一个软中断信号通知下半部做进一步的处理。半部被软中断信号唤醒后需要从内存中找到网络数据再按照网络协议栈对数据进行逐层解析和处理直到把它送给应用程序也就是上半部直接处理硬件请求也就是我们常说的硬中断特点是快速处理中断下半部则是由内核触发也就是我们常说的软中断特点是延迟执行,用来异步处理上半部未完成的工作。实际上上半部会打断 CPU 正在执行的任务然后立即执行中断处理程序。而下半部以内核线程的方式执行并且每个 CPU 都对应一个软中断内核线程名字为 “ksoftirqd/CPU 编号”比如说 0 号 CPU 对应的软中断内核线程的名字就是 ksoftirqd/0。#查看这些软中断内核线程的运行状况 #这些线程的名字外面都有中括号这说明 ps 无法获取它们的命令行参数cmline。一般来说ps 的输出中名字括在中括号里的一般都是内核线程。 $ ps aux | grep softirq root 7 0.0 0.0 0 0 ? S Oct10 0:01 [ksoftirqd/0] root 16 0.0 0.0 0 0 ? S Oct10 0:01 [ksoftirqd/1]软中断不只包括了刚刚所讲的硬件设备中断处理程序的下半部一些内核自定义的事件也属于软中断比如内核调度和 RCU 锁Read-Copy Update 的缩写RCU 是 Linux 内核中最常用的锁之一等。(3)查看软中断和内核线程Linux 中的软中断包括网络收发、定时、调度、RCU 锁等各种类型/proc/softirqs 提供了软中断的运行情况/proc/interrupts 提供了硬中断的运行情况。$ cat /proc/softirqs CPU0 CPU1 HI: 0 0 TIMER: 811613 1972736 NET_TX: 49 7 NET_RX: 1136736 1506885 BLOCK: 0 0 IRQ_POLL: 0 0 TASKLET: 304787 3691 SCHED: 689718 1897539 HRTIMER: 0 0 RCU: 1330771 1354737第一要注意软中断的类型(第一列)。从第一列你可以看到软中断包括了 10 个类别分别对应不同的工作类型。比如 NET_RX 表示网络接收中断而 NET_TX 表示网络发送中断。第二要注意同一种软中断在不同 CPU 上的分布情况也就是同一行的内容。正常情况下同一种中断在不同 CPU 上的累积次数应该差不多。比如这个界面中NET_RX 在 CPU0 和 CPU1 上的中断次数基本是同一个数量级相差不大。不过你可能发现TASKLET 在不同 CPU 上的分布并不均匀。TASKLET 是最常用的软中断实现机制每个 TASKLET 只运行一次就会结束 并且只在调用它的函数所在的 CPU 上运行。因此使用 TASKLET 特别简便当然也会存在一些问题比如说由于只在一个 CPU 上运行导致的调度不均衡再比如因为不能在多个 CPU 上并行运行带来了性能限制。当软中断事件的频率过高时内核线程也会因为 CPU 使用率过高而导致软中断处理不及时进而引发网络收发延迟、调度缓慢等性能问题。5CPU 使用率过高怎么办通过 top、ps、pidstat 等工具找到 CPU 使用率较高比如 100% 的进程。占用 CPU 的到底是代码里的哪个函数呢GDBThe GNU Project DebuggerGDB 在调试程序错误方面很强大。GDB 并不适合在性能分析的早期应用。因为 GDB 调试程序的过程会中断程序运行这在线上环境往往是不允许的。所以GDB 只适合用在性能分析的后期当你找到了出问题的大致函数后线下再借助它来进一步调试函数内部的问题。perf是 Linux 2.6.31 以后内置的性能分析工具。它以性能事件采样为基础不仅可以分析系统的各种事件和内核性能还可以用来分析指定应用程序的性能问题。使用 perf 分析 CPU 性能问题两种最常见用法。第一种常见用法是perf top类似于 top它能够实时显示占用 CPU 时钟最多的函数或者指令因此可以用来查找热点函数使用界面如下所示$ perf top Samples: 833 of event cpu-clock, Event count (approx.): 97742399 Overhead Shared Object Symbol 7.28% perf [.] 0x00000000001f78a4 4.72% [kernel] [k] vsnprintf 4.32% [kernel] [k] module_get_kallsym 3.65% [kernel] [k] _raw_spin_unlock_irqrestore ...输出结果中第一行包含三个数据分别是采样数Samples、事件类型event和事件总数量Event count。比如这个例子中perf 总共采集了 833 个 CPU 时钟事件而总事件数则为 97742399。另外采样数需要我们特别注意。如果采样数过少比如只有十几个那下面的排序和百分比就没什么实际参考价值了。再往下看是一个表格式样的数据每一行包含四列分别是第一列 Overhead 是该符号的性能事件在所有采样中的比例用百分比来表示。第二列 Shared 是该函数或指令所在的动态共享对象Dynamic Shared Object如内核、进程名、动态链接库名、内核模块名等。第三列 Object 是动态共享对象的类型。比如 [.] 表示用户空间的可执行程序、或者动态链接库而 [k] 则表示内核空间。最后一列 Symbol 是符号名也就是函数名。当函数名未知时用十六进制的地址来表示。还是以上面的输出为例我们可以看到占用 CPU 时钟最多的是 perf 工具自身不过它的比例也只有 7.28%说明系统并没有 CPU 性能问题。 perf top 的使用你应该很清楚了吧。第二种常见用法perf record 和 perf report。 perf top 虽然实时展示了系统的性能信息但它的缺点是并不保存数据也就无法用于离线或者后续的分析。而 perf record 则提供了保存数据的功能保存后的数据需要你用 perf report 解析展示。$ perf record # 按CtrlC终止采样 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.452 MB perf.data (6093 samples) ] $ perf report # 展示类似于perf top的报告在实际使用中我们还经常为 perf top 和 perf record 加上 -g 参数开启调用关系的采样方便我们根据调用链来分析性能问题.6CPU异常排查思路1cpu使用率清楚用户%user、Nice%nice、系统%system 、等待 I/O%iowait 、中断%irq以及软中断%softirq这几种不同 CPU 的使用率。比如说用户态 CPU 使用率user和低优先级用户态 CPU 使用率nice高说明用户态进程占用了较多的 CPU所以应该着重排查进程的性能问题。系统 CPU不包括中断 高说明内核态占用了较多的 CPU所以应该着重排查内核线程或者系统调用的性能问题。I/O 等待 CPU 高说明等待 I/O 的时间比较长系统与硬件设备的 I/O 交互时间比较长所以应该着重排查系统存储是不是出现了 I/O 问题。软中断和硬中断高说明内核调用软中断或硬中断的处理程序占用了较多的 CPU说明系统发生了大量的中断所以应该着重排查内核中的中断服务程序。虚拟化环境中会用到的窃取 CPU 使用率steal和客户 CPU 使用率guest分别表示被其他虚拟机占用的 CPU 时间百分比和运行客户虚拟机的 CPU 时间百分比。2平均负载Load Average系统的平均活跃进程数。它反应了系统的整体负载情况主要包括三个数值分别指过去 1 分钟、过去 5 分钟和过去 15 分钟的平均负载。平均负载等于逻辑 CPU 个数这表示每个 CPU 都恰好被充分利用。如果平均负载大于逻辑 CPU 个数就表示负载比较重了。我们先用 uptime 查看了系统的平均负载而在平均负载升高后又用 mpstat 和 pidstat 分别观察了每个 CPU 和每个进程 CPU 的使用情况进而找出了导致平均负载升高的进程也就是我们的压测工具 stress。见前面平均负载的文章3进程上下文切换无法获取资源而导致的自愿上下文切换被系统强制调度导致的非自愿上下文切换。过多的上下文切换会将原本运行进程的 CPU 时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上缩短进程真正运行的时间成为性能瓶颈。上下文切换的案例。我们先用 vmstat 查看了系统的上下文切换次数和中断次数然后通过 pidstat 观察了进程的自愿上下文切换和非自愿上下文切换情况最后通过 pidstat 观察了线程的上下文切换情况找出了上下文切换次数增多的根源也就是我们的基准测试工具 sysbench。见前面上下文切换的文章4CPU 缓存的命中率CPU 发展的速度远快于内存的发展CPU 的处理速度就比内存的访问速度快得多。这样CPU 在访问内存的时候免不了要等待内存的响应。为了协调这两者巨大的性能差距CPU 缓存通常是多级缓存就出现了CPU 缓存的速度介于 CPU 和内存之间缓存的是热点的内存数据。根据不断增长的热点数据这些缓存按照大小不同分为 L1、L2、L3 等三级缓存其中 L1 和 L2 常用在单核中 L3 则用在多核中。从 L1 到 L3三级缓存的大小依次增大相应的性能依次降低当然比内存还是好得多。而它们的命中率衡量的是 CPU 缓存的复用情况命中率越高则表示性能越好。7CPU性能工具1根据指标找工具性能指标工具说明平均负载uptimetopuptime最简单top提供了更全的指标系统整体CPU使用率vmstatmpstattopsar/proc/stattop、vmstat、mpstat只可以动态查看而sar还可以记录历史数据/proc/stat是其他性能工具的数据来源进程CPU使用率toppidstatpshtopatoptop和ps可以按CPU使用率给进程排序而pidstat只显示实际用了CPU的进程htop和atop以不同颜色显示更直观系统上下文切换vmstat除了上下文切换次数还提供运行状态和不可中断状态进程的数量进程上下文切换pidstat注意加上-w选项软中断top/proc/softirqsmpstattop提供软中断CPU使用率而/proc/softirqs和mpstat提供了各种软中断在每个CPU上的运行次数硬中断vmstat/proc/interruptsvmstat提供总的中断次数而/proc/interrupts提供各种中断在每个CPU上运行的累积次数网络dstatsartcpdumpdstat和sar提供总的网络接收和发送情况而tcpdump则是动态抓取正在进行的网络通讯I/Odstatsardstat和sar都提供了I/O的整体情况CPU 个数/proc/cpuinfolscpulscpu更直观事件剖析perfexecsnoopperf可以用来分析CPU的缓存以及内核调用链execsnoop用来监控短时进程2从工具角度每个工具能做什么性能工具CPU性能指标uptime平均负载top平均负载、运行队列、整体的CPU使用率以及每个进程的状态和CPU使用率htoptop增强版以不同颜色区分不同类型的进程更直观atopCPU、内存、磁盘和网络等各种资源的全面监控vmstat系统整体的CPU使用率、上下文切换次数、中断次数还包括处于运行和不可中断状态的进程数量mpstat每个CPU的使用率和软中断次数pidstat进程和线程的CPU使用率、中断上下文切换次数/proc/softirqs软中断类型和在每个CPU上的累积中断次数/proc/interrupts硬中断类型和在每个CPU上的累积中断次数ps每个进程的状态和CPU使用率pstree进程的父子关系dstat系统整体的CPU使用率sar系统整体的CPU使用率包括可配置的历史数据strace进程的系统调用perfCPU性能事件剖析如调用链分析、CPU缓存、CPU调度等execsnoop监控短时进程8迅速分析 CPU 的性能瓶颈想弄清楚性能指标的关联性就要通晓每种性能指标的工作原理先运行几个支持指标较多的工具如 top、vmstat 和 pidstat从 top 的输出可以得到各种 CPU 使用率以及僵尸进程和平均负载等信息。从 vmstat 的输出可以得到上下文切换次数、中断次数、运行状态和不可中断状态的进程数。从 pidstat 的输出可以得到进程的用户 CPU 使用率、系统 CPU 使用率、以及自愿上下文切换和非自愿上下文切换情况。第一个例子pidstat 输出的进程用户 CPU 使用率升高会导致 top 输出的用户 CPU 使用率升高。所以当发现 top 输出的用户 CPU 使用率有问题时可以跟 pidstat 的输出做对比观察是否是某个进程导致的问题。而找出导致性能问题的进程后就要用进程分析工具来分析进程的行为比如使用 strace 分析系统调用情况以及使用 perf 分析调用链中各级函数的执行情况。第二个例子top 输出的平均负载升高可以跟 vmstat 输出的运行状态和不可中断状态的进程数做对比观察是哪种进程导致的负载升高。如果是不可中断进程数增多了那么就需要做 I/O 的分析也就是用 dstat 或 sar 等工具进一步分析 I/O 的情况。如果是运行状态进程数增多了那就需要回到 top 和 pidstat找出这些处于运行状态的到底是什么进程然后再用进程分析工具做进一步分析。最后一个例子当发现 top 输出的软中断 CPU 使用率升高时可以查看 /proc/softirqs 文件中各种类型软中断的变化情况确定到底是哪种软中断出的问题。比如发现是网络接收中断导致的问题那就可以继续用网络分析工具 sar 和 tcpdump 来分析。