本文作者:allenxguo,腾讯 QQ 音乐后台开发工程师
系统平均负载简介系统平均负载:是处于可运行或不可中断状态的平均进程数。 可运行进程:使用 CPU 或等待使用 CPU 的进程 不可中断状态进程:正在等待某些 IO 访问,一般是和硬件交互,不可被打断(不可被打断的原因是为了保护系统数据一致,防止数据读取错误) 查看系统平均负载首先top命令查看进程运行状态,如下: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND10760 user 20 0 3061604 84832 5956 S 82.4 0.6 126:47.61 Process29424 user 20 0 54060 2668 1360 R 17.6 0.0 0:00.03 **top** 程序状态Status进程可运行状态为R,不可中断运行为D(后续讲解 top 时会详细说明) top查看系统平均负载:
这里的load average就表示系统最近 1 分钟、5 分钟、15 分钟的系统瓶颈负载。 uptime查看系统瓶颈负载 [root /home/user]# uptime 13:11:01 up 888 days, 21:33, 8 users, load average: 17.20, 14.85, 14.10 查看 CPU 核信息系统平均负载和 CPU 核数密切相关,我们可以通过以下命令查看当前机器 CPU 信息: lscpu查看 CPU 信息:
cat /proc/cpuinfo查看每个 CPU 核的信息: processor : 7 // 核编号7vendor_id : GenuineIntelcpu family : 6model : 6... 系统平均负载升高的原因一般来说,系统平均负载升高意味着 CPU 使用率上升。但是他们没有必然联系,CPU 密集型计算任务较多一般系统平均负载会上升,但是如果 IO 密集型任务较多也会导致系统平均负载升高但是此时的 CPU 使用率不一定高,可能很低因为很多进程都处于不可中断状态,等待 CPU 调度也会升高系统平均负载。 所以假如我们系统平均负载很高,但是 CPU 使用率不是很高,则需要考虑是否系统遇到了 IO 瓶颈,应该优化 IO 读写速度。 所以系统是否遇到 CPU 瓶颈需要结合 CPU 使用率,系统瓶颈负载一起查看(当然还有其他指标需要对比查看,下面继续讲解) 案例问题排查stress是一个施加系统压力和压力测试系统的工具,我们可以使用stress工具压测试 CPU,以便方便我们定位和排查 CPU 问题。
stress 命令使用 // --cpu 8:8个进程不停的执行sqrt()计算操作 // --io 4:4个进程不同的执行sync()io操作(刷盘) // --vm 2:2个进程不停的执行malloc()内存申请操作 // --vm-bytes 128M:限制1个执行malloc的进程申请内存大小 stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10s 我们这里主要验证 CPU、IO、进程数过多的问题 CPU 问题排查使用stress -c 1模拟 CPU 高负载情况,然后使用如下命令观察负载变化情况: uptime:使用uptime查看此时系统负载:
mpstat:使用mpstat -P ALL 1则可以查看每一秒的 CPU 每一核变化信息,整体和top类似,好处是可以把每一秒(自定义)的数据输出方便观察数据的变化,最终输出平均数据: 13:14:53 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle13:14:58 all 12.89 0.00 0.18 0.00 0.00 0.03 0.00 0.00 0.00 86.9113:14:58 0 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0013:14:58 1 0.40 0.00 0.20 0.00 0.00 0.20 0.00 0.00 0.00 99.20 由以上输出可以得出结论,当前系统负载升高,并且其中 1 个核跑满主要在执行用户态任务,此时大多数属于业务工作。所以此时需要查哪个进程导致单核 CPU 跑满: pidstat:使用pidstat -u 1则是每隔 1 秒输出当前系统进程、CPU 数据:
top:当然最方便的还是使用top命令查看负载情况: top - 13:19:06 up 125 days, 20:01, 3 users, load average: 0.99, 0.63, 0.42Tasks: 223 total, 2 running, 221 sleeping, 0 stopped, 0 zombie%Cpu(s): 14.5 us, 0.3 sy, 0.0 ni, 85.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 stKiB Mem : 16166056 total, 3118532 free, 9550108 used, 3497416 buff/cacheKiB Swap: 0 total, 0 free, 0 used. 6447640 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND3150617 root 20 0 10384 120 0 R 100.0 0.0 4:36.89 stress 此时可以看到是stress占用了很高的 CPU。 IO 问题排查我们使用stress -i 1来模拟 IO 瓶颈问题,即死循环执行 sync 刷盘操作: uptime:使用uptime查看此时系统负载:
mpstat:查看此时 IO 消耗,但是实际上我们发现这里 CPU 基本都消耗在了 sys 即系统消耗上。 Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idleAverage: all 0.33 0.00 12.64 0.13 0.00 0.00 0.00 0.00 0.00 86.90Average: 0 0.00 0.00 99.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00Average: 1 0.00 0.00 0.33 0.00 0.00 0.00 0.00 0.00 0.00 99.67 IO 无法升高的问题: iowait 无法升高的问题,是因为案例中 stress 使用的是 sync()系统调用,它的作用是刷新缓冲区内存到磁盘中。对于新安装的虚拟机,缓冲区可能比较小,无法产生大的 IO 压力,这样大部分就都是系统调用的消耗了。所以,你会看到只有系统 CPU 使用率升高。解决方法是使用 stress 的下一代 stress-ng,它支持更丰富的选项,比如stress-ng -i 1 --hdd 1 --timeout 600(--hdd 表示读写临时文件)。
pidstat:同上(略) 可以看出 CPU 的 IO 升高导致系统平均负载升高。我们使用pidstat查找具体是哪个进程导致 IO 升高的。 top:这里使用 top 依旧是最方面的查看综合参数,可以得出stress是导致 IO 升高的元凶。 pidstat 没有 iowait 选项:可能是 CentOS 默认的sysstat太老导致,需要升级到 11.5.5 之后的版本才可用。 进程数过多问题排查进程数过多这个问题比较特殊,如果系统运行了很多进程超出了 CPU 运行能,就会出现等待 CPU 的进程。 使用stress -c 24来模拟执行 24 个进程(我的 CPU 是 8 核) uptime:使用uptime查看此时系统负载: $ watch -d uptime..., load average: 18.50, 7.13, 2.84 mpstat:同上(略) pidstat:同上(略) 可以观察到此时的系统处理严重过载的状态,平均负载高达 18.50。 top:我们还可以使用top命令查看此时Running状态的进程数,这个数量很多就表示系统正在运行、等待运行的进程过多。 总结通过以上问题现象及解决思路可以总结出:
总结工具:mpstat、pidstat、top和uptime CPU 上下文切换CPU 上下文:CPU 执行每个任务都需要知道任务从哪里加载、又从哪里开始运行,也就是说,需要系统事先帮它设置好 CPU 寄存器和程序计数器(Program Counter,PC)包括 CPU 寄存器在内都被称为 CPU 上下文。 CPU 上下文切换:CPU 上下文切换,就是先把前一个任务的 CPU 上下文(也就是 CPU 寄存器和程序计数器)保存起来,然后加载新任务的上下文到这些寄存器和程序计数器,最后再跳转到程序计数器所指的新位置,运行新任务。 CPU 上下文切换:分为进程上下文切换、线程上下文切换以及中断上下文切换。 进程上下文切换从用户态切换到内核态需要通过系统调用来完成,这里就会发生进程上下文切换(特权模式切换),当切换回用户态同样发生上下文切换。 一般每次上下文切换都需要几十纳秒到数微秒的 CPU 时间,如果切换较多还是很容易导致 CPU 时间的浪费在寄存器、内核栈以及虚拟内存等资源的保存和恢复上,这里同样会导致系统平均负载升高。 Linux 为每个 CPU 维护一个就绪队列,将 R 状态进程按照优先级和等待 CPU 时间排序,选择最需要的 CPU 进程执行。这里运行进程就涉及了进程上下文切换的时机:
线程上下文切换线程和进程:
所以线程上下文切换包括了 2 种情况:
中断上下文切换中断处理会打断进程的正常调度和执行,转而调用中断处理程序,响应设备事件。而在打断其他进程时,就需要将进程当前的状态保存下来,这样在中断结束后,进程仍然可以从原来的状态恢复运行。 对同一个 CPU 来说,中断处理比进程拥有更高的优先级,所以中断上下文切换并不会与进程上下文切换同时发生。由于中断会打断正常进程的调度和执行,所以大部分中断处理程序都短小精悍,以便尽可能快的执行结束。 查看系统上下文切换vmstat:工具可以查看系统的内存、CPU 上下文切换以及中断次数:
cs:则为每秒的上下文切换次数。 in:则为每秒的中断次数。 r:就绪队列长度,正在运行或等待 CPU 的进程。 b:不可中断睡眠状态的进程数,例如正在和硬件交互。 pidstat:使用pidstat -w选项查看具体进程的上下文切换次数: $ pidstat -w -p 3217281 110:19:13 UID PID cswch/s nvcswch/s Command10:19:14 0 3217281 0.00 18.00 stress10:19:15 0 3217281 0.00 18.00 stress10:19:16 0 3217281 0.00 28.71 stress 其中cswch/s和nvcswch/s表示自愿上下文切换和非自愿上下文切换。 自愿上下文切换:是指进程无法获取所需资源,导致的上下文切换。比如说, I/O、内存等系统资源不足时,就会发生自愿上下文切换。 非自愿上下文切换:则是指进程由于时间片已到等原因,被系统强制调度,进而发生的上下文切换。比如说,大量进程都在争抢 CPU 时,就容易发生非自愿上下文切换 案例问题排查这里我们使用sysbench工具模拟上下文切换问题。 先使用vmstat 1查看当前上下文切换信息:
然后使用sysbench --threads=64 --max-time=300 threads run模拟 64 个线程执行任务,此时我们再次vmstat 1查看上下文切换信息: $ vmstat 1procs -----------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 318792 3385728 5474272 0 0 10 16 0 0 4 1 95 0 0 1 0 0 307492 3385756 5474316 0 0 8 0 15710 20569 20 8 72 0 0 1 0 0 330032 3385824 5474376 0 0 8 16 21573 26844 19 9 72 0 0 2 0 0 321264 3385876 5474396 0 0 12 0 21218 26100 20 7 73 0 0 6 0 0 320172 3385932 5474440 0 0 12 0 19363 23969 19 8 73 0 014 0 0 323488 3385980 5474828 0 0 64 788 111647 3745536 24 61 15 0 014 0 0 323576 3386028 5474856 0 0 8 0 118383 4317546 25 64 11 0 016 0 0 315560 3386100 5475056 0 0 8 16 115253 4553099 22 68 9 0 0 我们可以明显的观察到:
分析 cs 上下文切换问题我们使用pidstat查看当前 CPU 信息和具体的进程上下文切换信息:
所以我们可以看到大量的sysbench线程存在很多的上下文切换。 分析 in 中断问题我们可以查看系统的watch -d cat /proc/softirqs以及watch -d cat /proc/interrupts来查看系统的软中断和硬中断(内核中断)。我们这里主要观察/proc/interrupts即可。 $ watch -d cat /proc/interruptsRES: 900997016 912023527 904378994 902594579 899800739 897500263 895024925 895452133 Rescheduling interrupts 这里明显看出重调度中断(RES)增多,这个中断表示唤醒空闲状态 CPU 来调度新任务执行, 总结
CPU 使用率除了系统负载、上下文切换信息,最直观的 CPU 问题指标就是 CPU 使用率信息。Linux 通过/proc虚拟文件系统向用户控件提供系统内部状态信息,其中/proc/stat则是 CPU 和任务信息统计。
这里每一列的含义如下:
这里我们可以使用top、ps、pidstat等工具方便的查询这些数据,可以很方便的看到 CPU 使用率很高的进程,这里我们可以通过这些工具初步定位,但是具体的问题原因还需要其他方法继续查找。 这里我们可以使用perf top方便查看热点数据,也可以使用perf record可以将当前数据保存起来方便后续使用perf report查看。 CPU 使用率问题排查这里总结一下 CPU 使用率问题及排查思路:
CPU 问题排查套路CPU 使用率CPU 使用率主要包含以下几个方面:
平均负载反映了系统的整体负载情况,可以查看过去 1 分钟、过去 5 分钟和过去 15 分钟的平均负载。 上下文切换上下文切换主要关注 2 项指标:
CPU 缓存命中率CPU 的访问速度远大于内存访问,这样在 CPU 访问内存时不可避免的要等待内存响应。为了协调 2 者的速度差距出现了 CPU 缓存(多级缓存)。 如果 CPU 缓存命中率越高则性能会更好,我们可以使用以下工具查看 CPU 缓存命中率,工具地址、项目地址 perf-tools # ./cachestat -tCounting cache functions... Output every 1 seconds.TIME HITS MISSES DIRTIES RATIO BUFFERS_MB CACHE_MB08:28:57 415 0 0 100.0% 1 19108:28:58 411 0 0 100.0% 1 19108:28:59 362 97 0 78.9% 0 808:29:00 411 0 0 100.0% 0 908:29:01 775 20489 0 3.6% 0 8908:29:02 411 0 0 100.0% 0 8908:29:03 6069 0 0 100.0% 0 8908:29:04 15249 0 0 100.0% 0 8908:29:05 411 0 0 100.0% 0 8908:29:06 411 0 0 100.0% 0 8908:29:07 411 0 3 100.0% 0 89[...] 总结通过性能指标查工具(CPU 相关)性能指标工具说明平均负载uptime topuptime 简单展示最近一段时间的平均负载 top 展示更多指标CPU 使用率vmstat mpstat top sar /proc/stat top、vmstat、mpstat 只可以动态查看当前,而 sar 可以查看历史 /proc/stat 是其他性能工具的数据来源进程 CPU 使用率top pidstat ps htop atop top、ps 可以以排序方式展示进程 CPU、pidstat 不可排序展示 htop、atop 则以不同颜色展示各类数据更直观系统上下文切换vmstat展示上下文切换此时、运行状态、不可中断状态进程数量进程上下文切换pidstat展示项很多,包括进程上下文切换信息软中断top /proc/softirqs mpstattop 可查看软中断 CPU 使用率 /proc/softirqs 和 mpstat 则可以查看每个 CPU 上的累计信息硬中断vmstat /proc/interruptsvmstat 查看总中断次数信息 /proc/interrupts 查看各种中断在每个 CPU 核心上的累计信息网络dstat sar tcpdumpdstat、sar 较详细的展示出总的网络收发情况 tcpdump 提供动态抓取数据包的能力IOdstat、sar2 这都提供了详细的 IO 整体情况CPU 信息/proc/cpuinfo lscpu都可以查看 CPU 信息系统分析perf execsnoopperf 分析各种内核函数调用、热点函数信息 execsnoop 监控短时进程 根据工具查性能指标(CPU 相关)性能工具CPU 性能指标uptime5、10、15 分钟内的平均负载展示top平均负载、运行队列、CPU 各项使用率、进程状态和 CPU 使用率htoptop 增强版,以不同颜色区分不同类型进程,展示更直观atopCPU、内存、磁盘、网络资源全访问监控,十分齐全vmstat系统整体 CPU 使用率、上下文切换次数、中断次数,还包括处于运行(r)和不可中断状态(b)的进程数量pidstat进程、线程(-t)的每个 CPU 占用信息,中断上下文切换次数/proc/softirqs展示每个 CPU 上的软中断类型及次数/proc/inerrupts展示每个 CPU 上的硬中断类型及次数ps每个进程的状态和 CPU 使用率pstree进程的父子关系展示dstat系统整体 CPU 使用率(以及相关 IO、网络信息)sar系统整体 CPU 使用率,以及使用率历史信息strace跟踪进程的系统调用perfCPU 性能事件分析,例如:函数调用链、CPU 缓存命中率、CPU 调度等execsnoop短时进程分析 CPU 问题排查方向有了以上性能工具,在实际遇到问题时我们并不可能全部性能工具跑一遍,这样效率也太低了,所以这里可以先运行几个常用的工具 top、vmstat、pidstat 分析系统大概的运行情况然后在具体定位原因。
CPU 问题优化方向性能优化往往是多方面的,CPU、内存、网络等都是有关联的,这里暂且给出 CPU 优化的思路,以供参考。 程序优化
系统优化
参考 极客时间:Linux 性能优化实战 |
|