延边州网站建设,新手自学做网站多久,邢台做网站哪里便宜,小程序开发平台的设计是实现简介#xff1a; 浅谈 Linux 高负载的系统化分析#xff0c;阿里云系统组工程师杨勇通过对线上各种问题的系统化分析。
讲解 Linux Load 高如何排查的话题属于老生常谈了#xff0c;但多数文章只是聚焦了几个点#xff0c;缺少整体排查思路的介绍。所谓 “授人以鱼不如授人…简介 浅谈 Linux 高负载的系统化分析阿里云系统组工程师杨勇通过对线上各种问题的系统化分析。
讲解 Linux Load 高如何排查的话题属于老生常谈了但多数文章只是聚焦了几个点缺少整体排查思路的介绍。所谓 “授人以鱼不如授人以渔”。本文试图建立一个方法和套路来帮助读者对 Load 高问题排查有一个更全面的认识。
从消除误解开始
没有基线的 Load是不靠谱的 Load
从接触 Unix/Linux 系统管理的第一天起很多人就开始接触 System Load Average 这个监控指标了然而并非所有人都知道这个指标的真正含义。一般说来经常能听到以下误解
Load 高是 CPU 负载高…… 传统 Unix 于 Linux 设计不同。Unix 系统Load 高就是可运行进程多引发的但对 Linux 来说不是。对 Linux 来说 Load 高可能有两种情况
系统中处于 R 状态的进程数增加引发的系统中处于 D 状态的进程数增加引发的
Loadavg 数值大于某个值就一定有问题…… Loadavg 的数值是相对值受到 CPU 和 IO 设备多少的影响甚至会受到某些软件定义的虚拟资源的影响。Load 高的判断需要基于某个历史基线 (Baseline)不能无原则的跨系统去比较 Load。Load 高系统一定很忙….. Load 高系统可以很忙例如 CPU 负载高CPU 很忙。但 Load 高系统不都很忙如 IO 负载高磁盘可以很忙但 CPU 可以比较空闲如 iowait 高。这里要注意iowait 本质上是一种特殊的 CPU 空闲状态。另一种 Load 高可能 CPU 和磁盘外设都很空闲可能支持锁竞争引起的这时候 CPU 时间里iowait 不高但 idle 高。
Brendan Gregg 在最近的博客 [Linux Load Averages: Solving the Mystery] (http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html) 中讨论了 Unix 和 Linux Load Average 的差异并且回朔到 24 年前 Linux 社区的讨论并找到了当时为什么 Linux 要修改 Unix Load Average 的定义。文章认为正是由于 Linux 引入的 D 状态线程的计算方式从而导致 Load 高的原因变得含混起来。因为系统中引发 D 状态切换的原因实在是太多了绝非 IO 负载锁竞争这么简单正是由于这种含混Load 的数值更加难以跨系统跨应用类型去比较。所有 Load 高低的依据全都应该基于历史的基线。本微信公众号也曾写过一篇相关文章可以参见Linux Load Average那些事儿。 如何排查 Load 高的问题
如前所述由于在 Linux 操作系统里Load 是一个定义及其含混的指标排查 loadavg 高就是一个很复杂的过程。其基本思路就是根据引起 Load 变化的根源是 R 状态任务增多还是 D 状态任务增多来进入到不同的流程。
这里给出了 Load 增高的排查的一般套路仅供参考 在 Linux 系统里读取 /proc/stat 文件即可获取系统中 R 状态的进程数但 D 状态的任务数恐怕最直接的方式还是使用 ps 命令比较方便。而 /proc/stat 文件里 procs_blocked 则给出的是处于等待磁盘 IO 的进程数 通过简单区分 R 状态任务增多还是 D 状态任务增多我们就可以进入到不同的排查流程里。下面我们就这个大图的排查思路做一个简单的梳理。
R 状态任务增多
即通常所说的 CPU 负载高。此类问题的排查定位主要思路是系统容器进程的运行时间分析上找到在 CPU 上的热点路径或者分析 CPU 的运行时间主要是在哪段代码上。
CPU user 和 sys 时间的分布通常能帮助人们快速定位与用户态进程有关还是与内核有关。另外CPU 的 run queue 长度和调度等待时间非主动的上下文切换 (nonvoluntary context switch) 次数都能帮助大致理解问题的场景。
因此如果要将问题的场景关联到相关的代码通常需要使用 perfsystemtap, ftrace 这种动态的跟踪工具。
关联到代码路径后接下来的代码时间分析过程中代码中的一些无效的运行时间也是分析中首要关注的例如用户态和内核态中的自旋锁 (Spin Lock)。
当然如果 CPU 上运行的都是有非常意义非常有效率的代码那唯一要考虑的就是是不是负载真得太大了。
D 状态任务增多
根据 Linux 内核的设计 D 状态任务本质上是 TASK_UNINTERRUPTIBLE 引发的主动睡眠因此其可能性非常多。但是由于 Linux 内核 CPU 空闲时间上对 IO 栈引发的睡眠做了特殊的定义即 iowait因此iowait 成为 D 状态分类里定位是否 Load 高是由 IO 引发的一个重要参考。
当然如前所述 /proc/stat 中的 procs_blocked 的变化趋势也可以是一个非常好的判定因 iowait引发的 Load 高的一个参考。
CPU iowait 高
很多人通常都对 CPU iowait 有一个误解以为 iowait 高是因为这时的 CPU 正在忙于做 IO 操作。其实恰恰相反 iowait 高的时候CPU 正处于空闲状态没有任何任务可以运行。只是因为此时存在已经发出的磁盘 IO因此这时的空闲状态被标识成了 iowait 而不是 idle。
但此时如果用 perf probe 命令我们可以清楚得看到在 iowait 状态的 CPU实际上是运行在 pid 为 0 的 idle 线程上 相关的 idle 线程的循环如何分别对 CPU iowait 和 idle 计数的代码如下所示 而 Linux IO 栈和文件系统的代码则会调用 io_schedule等待磁盘 IO 的完成。这时候对 CPU 时间被记为 iowait 起关键计数的原子变量 rq-nr_iowait 则会在睡眠前被增加。注意io_schedule 在被调用前通常 caller 会先将任务显式地设置成 TASK_UNINTERRUPTIBLE 状态 CPU idle 高
如前所述有相当多的内核的阻塞即 TASK_UNINTERRUPTIBLE 的睡眠实际上与等待磁盘 IO 无关如内核中的锁竞争再如内存直接页回收的睡眠又如内核中一些代码路径上的主动阻塞等待资源。
Brendan Gregg 在最近的博客 [Linux Load Averages: Solving the Mystery] (http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html)中使用 perf 命令产生的 TASK_UNINTERRUPTIBLE 的睡眠的火焰图很好的展示了引起 CPU idle 高的多样性。本文不在赘述。
因此CPU idle 高的分析实质上就是分析内核的代码路径引起阻塞的主因是什么。通常我们可以使用 perf inject 对 perf record 记录的上下文切换的事件进行处理关联出进程从 CPU 切出 (swtich out) 和再次切入 (switch in) 的内核代码路径生成一个所谓的 Off CPU 火焰图.
当然类似于锁竞争这样的比较简单的问题Off CPU 火焰图足以一步定位出问题。但是对于更加复杂的因 D 状态而阻塞的延迟问题可能 Off CPU 火焰图只能给我们一个调查的起点。
例如当我们看到Off CPU 火焰图的主要睡眠时间是因为 epoll_wait 等待引发的。那么我们继续要排查的应该是网络栈的延迟即本文大图中的 Net Delay 这部分。
至此你也许会发现CPU iowait 和 idle 高的性能分析的实质就是 延迟分析。这就是大图按照内核中资源管理的大方向将延迟分析细化成了六大延迟分析
CPU 延迟内存延迟文件系统延迟IO 栈延迟网络栈延迟锁及同步原语竞争
任何上述代码路径引发的 TASK_UNINTERRUPTIBLE 的睡眠都是我们要分析的对象
以问题结束
限于篇幅本文很难将其所涉及的细节一一展开因为读到这里你也许会发现原来 Load 高的分析实际上就是对系统的全面负载分析。怪不得叫 System Load 呢。这也是 Load 分析为什么很难在一篇文章里去全面覆盖。
本文也开启了浅谈 Linux 性能分析系列的第一章。后续我们会推出系列文章就前文所述的六大延迟分析一一展开介绍敬请期待……
关于作者
杨勇 (Oliver Yang)Linux 内核工程师来自阿里云系统组。曾就职于 EMCSun 中国工程研究院在存储系统和 Solaris 内核开发领域工作。
原文链接
本文为阿里云原创内容未经允许不得转载。
