0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看技术视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

建立一个方法和套路来对 Load 高问题排查

Linux阅码场 2017-12-28 14:18 次阅读

讲解 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, Brendan Gregg: Linux Load Averages究竟是个什么鬼?) 中,讨论了 Unix 和 Linux Load Average 的差异,并且回朔到 24 年前 Linux 社区的讨论,并找到了当时为什么 Linux 要修改 Unix Load Average 的定义。文章认为,正是由于 Linux 引入的D状态线程的计算方式,从而导致 Load 高的原因变得含混起来。因为系统中引发D状态切换的原因实在是太多了,绝非 IO 负载,锁竞争这么简单!正是由于这种含混,Load 的数值更加难以跨系统,跨应用类型去比较。所有 Load 高低的依据,全都应该基于历史的基线。本文无意过多搬运原文的内容,因此,进一步的细节,建议阅读原文。

如何排查 Load 高的问题

如前所述,由于在 Linux 操作系统里,Load 是一个定义及其含混的指标,排查 loadavg 高就是一个很复杂的过程。其基本思路就是,根据引起 Load 变化的根源是R状态任务增多,还是D状态任务增多,来进入到不同的流程。

这里给出了 Load 增高的排查的一般套路,仅供参考:

建立一个方法和套路来对 Load 高问题排查

在 Linux 系统里,读取/proc/stat文件,即可获取系统中R状态的进程数;但D状态的任务数恐怕最直接的方式还是使用ps命令比较方便。而/proc/stat文件里procs_blocked则给出的是处于等待磁盘 IO 的进程数:

$cat /proc/stat .......processes 50777849procs_running 1procs_blocked 0......

通过简单区分R状态任务增多,还是D状态任务增多,我们就可以进入到不同的排查流程里。下面,我们就这个大图的排查思路,做一个简单的梳理。

R状态任务增多

即通常所说的 CPU 负载高。此类问题的排查定位主要思路是系统,容器,进程的运行时间分析上,找到在 CPU 上的热点路径,或者分析 CPU 的运行时间主要是在哪段代码上。

CPUuser和sys时间的分布通常能帮助人们快速定位与用户态进程有关,还是与内核有关。另外,CPU 的 run queue 长度和调度等待时间,非主动的上下文切换 (nonvoluntary context switch) 次数都能帮助大致理解问题的场景。

因此,如果要将问题的场景关联到相关的代码,通常需要使用perf,systemtap,ftrace这种动态的跟踪工具。

关联到代码路径后,接下来的代码时间分析过程中,代码中的一些无效的运行时间也是分析中首要关注的,例如用户态和内核态中的自旋锁 (Spin Lock)。

当然,如果 CPU 上运行的都是有非常意义,非常有效率的代码,那唯一要考虑的就是,是不是负载真得太大了。

D状态任务增多

根据 Linux 内核的设计,D状态任务本质上是TASK_UNINTERRUPTIBLE引发的主动睡眠,因此其可能性非常多。但是由于 Linux 内核 CPU 空闲时间上对 IO 栈引发的睡眠做了特殊的定义,即iowait,因此iowait成为D状态分类里定位是否 Load 高是由 IO 引发的一个重要参考。

当然,如前所述,/proc/stat中的procs_blocked的变化趋势也可以是一个非常好的判定因iowait引发的 Load 高的一个参考。

CPUiowait高

很多人通常都对 CPUiowait有一个误解,以为iowait高是因为这时的 CPU 正在忙于做 IO 操作。其实恰恰相反,iowait高的时候,CPU 正处于空闲状态,没有任何任务可以运行。只是因为此时存在已经发出的磁盘 IO,因此这时的空闲状态被标识成了iowait,而不是idle。

但此时,如果用perf probe命令,我们可以清楚得看到,在iowait状态的 CPU,实际上是运行在 pid 为 0 的 idle 线程上:

$ sudo perf probe -a account_idle_ticks$sudo perf record -e probe:account_idle_ticks -ag sleep 1[ perf record: Woken up 1 times to write data ][ perf record: Captured and wrote 0.418 MB perf.data (843 samples) ]$sudo perf scriptswapper 0 [013] 5911414.451891: probe:account_idle_ticks: (ffffffff810b6af0) 2b6af1 account_idle_ticks (/lib/modules/3.10.0/build/vmlinux) 2d65d9 cpu_startup_entry (/lib/modules/3.10.0/build/vmlinux) 24840a start_secondary (/lib/modules/3.10.0/build/vmlinux)

相关的 idle 线程的循环如何分别对 CPUiowait和idle计数的代码,如下所示:

/*

* Account multiple ticks of idle time.

* @ticks: number of stolen ticks

*/

void account_idle_ticks(unsigned long ticks)

{

if (sched_clock_irqtime) {

irqtime_account_idle_ticks(ticks);

return;

}

account_idle_time(jiffies_to_cputime(ticks));

}

/*

* Account for idle time.

* @cputime: the cpu time spent in idle wait

*/

void account_idle_time(cputime_t cputime)

{

u64 *cpustat = kcpustat_this_cpu->cpustat;

struct rq *rq = this_rq();

if (atomic_read(&rq->nr_iowait) > 0)

cpustat[CPUTIME_IOWAIT] += (__force u64) cputime;

else

cpustat[CPUTIME_IDLE] += (__force u64) cputime;

}

而 Linux IO 栈和文件系统的代码则会调用io_schedule,等待磁盘 IO 的完成。这时候,对 CPU 时间被记为iowait起关键计数的原子变量rq->nr_iowait则会在睡眠前被增加。注意,io_schedule 在被调用前,通常 caller 会先将任务显式地设置成TASK_UNINTERRUPTIBLE状态:

/*

* This task is about to go to sleep on IO. Increment rq->nr_iowait so

* that process accounting knows that this is a task in IO wait state.

*/

void __sched io_schedule(void)

{

io_schedule_timeout(MAX_SCHEDULE_TIMEOUT);

}

EXPORT_SYMBOL(io_schedule);

long __sched io_schedule_timeout(long timeout)

{

int old_iowait = current->in_iowait;

struct rq *rq;

long ret;

current->in_iowait = 1;

if (old_iowait)

blk_schedule_flush_plug(current);

else

blk_flush_plug(current);

delayacct_blkio_start();

rq = raw_rq();

atomic_inc(&rq->nr_iowait);

ret = schedule_timeout(timeout);

current->in_iowait = old_iowait;

atomic_dec(&rq->nr_iowait);

delayacct_blkio_end();

return ret;

}

EXPORT_SYMBOL(io_schedule_timeout);

CPUidle高

如前所述,有相当多的内核的阻塞,即 TASK_UNINTERRUPTIBLE 的睡眠,实际上与等待磁盘 IO 无关,如内核中的锁竞争,再如内存直接页回收的睡眠,又如内核中一些代码路径上的主动阻塞,等待资源。

Brendan Gregg 在最近的博客 [Linux Load Averages: Solving the Mystery] 中,使用 perf 命令产生的 TASK_UNINTERRUPTIBLE 的睡眠的火焰图,很好的展示了引起 CPU idle 高的多样性。本文不在赘述。

建立一个方法和套路来对 Load 高问题排查

因此,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 性能分析系列的第一章。后续我们会推出系列文章,就前文所述的六大延迟分析,一一展开介绍,敬请期待......

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • Linux
    +关注

    关注

    87

    文章

    11300

    浏览量

    209404
  • Load
    +关注

    关注

    0

    文章

    9

    浏览量

    10656

原文标题:阿里杨勇:浅谈 Linux 高负载的系统化分析

文章出处:【微信号:LinuxDev,微信公众号:Linux阅码场】欢迎添加关注!文章转载请注明出处。

收藏 人收藏

    评论

    相关推荐

    描述mcp内核常见问题的排查方法帮助快速排查定位问题

    任何系统,硬件故障和软件故障都不可避免。比如车载系统,由于汽车行驶过程中的震动,发热,电瓶馈电等,很容易影响电子元件的特性,这对设备是致命的影响,会直接改变程序逻辑及运行结果从而产生各种不可预测的异常情况,本文描述常见问题的排查方法帮助快速
    的头像 发表于 07-12 09:23 2403次阅读
    描述mcp内核常见问题的<b class='flag-5'>排查</b><b class='flag-5'>方法</b>帮助快速<b class='flag-5'>排查</b>定位问题

    使用汇编知识排查疑难问题的方法

    那么,本篇文章,我将再介绍使用汇编知识排查疑难问题的方法,希望对大家有所帮助。
    发表于 07-27 10:31 673次阅读

    射频PA设计中的Load-line与Load-pull

    说到射频PA(Power Amplifier,功率放大器)的设计和应用,有两名词经常被大家提及:Load-line与Load-pull。在使用中,这两名词太过常用了,以至于对这两
    发表于 09-28 10:27 6147次阅读

    [转]硬件调试套路总结

    、何为调试,调试为何这并不是废话,作为菜鸟而言,面对块熟悉又陌生的板子如何下手调试也许并不是件So easy的事。什么是调试呢?简
    发表于 09-10 14:37

    IC设计基础:说说wire load model

    ,了解这模型,对理解多种工具的工作原理和使用都有帮助。 、什么是wire load model? 线性负载模型是由半导体工艺厂商根据自身工艺特点开发的,该模型包含单位长度面积因子、电容、电阻和
    发表于 05-21 18:30

    单片机组做题套路和技巧相关资料下载

    蓝桥杯比赛 单片机组 做题套路和技巧前言方法1、记模块2、分析框图3、循序渐进前言  完成完整的题目,需要你对各个模块的熟悉使用以及严密的逻辑思维,然而这还不够,在有限的时间完整的
    发表于 01-07 07:27

    STM32建立工程文件的方法

    这里写目录标题、STM 32程序1.建立工程文件2.选择STM32芯片3.对所选芯片进行设置4.编写源程序5.编译结果二、程序的仿真调试1.仿真前的设置(1)点击魔法棒,进入设置
    发表于 02-15 06:59

    GPIO无法触发中断常规排查方法有哪些?

    1、电源域是否打开 2、IOMUX是否设置对 3、是否配置了中断方式,外部电平是否满足条件 4、是否为输入状态 备注:这次分享的是,我们做展锐平台GPIO排查方法,不同平台、不同版本、不同项目都会
    发表于 11-24 16:11

    通过排查电能质量问题缩短停产时间

    通过排查电能质量问题缩短停产时间:不良电能质量是电机,照明装置以及IT网络等系统中所发生问题的潜在来源。采取主动措施以排查并解决不良电能质量问题,可以防止示经计
    发表于 11-26 17:44 24次下载

    网络故障排查思路和处理方法

    网络故障是最容易出现的,且难以解决的问题。本文提供的网络故障排查思路和处理方法,可解决日常工作中大部分网络问题。
    发表于 10-31 09:14 9581次阅读

    建立计算模型预测给定博文的抱怨强度

    在计算语言学中,先前的研究主要集中在建立自动分类模型识别抱怨是否存在。Jin提供了数据集,基于语用学注释了不同严重程度的抱怨博文
    的头像 发表于 11-08 09:54 620次阅读

    VxWorks里怎样load文件到内存?

    VxWorks里怎样load文件到内存? 这个文件可以是在SD、USB、ATA这类的存储设备,也可以通过ftp网络下载;
    的头像 发表于 06-16 09:32 1029次阅读

    小间距LED显示屏故障排查方法

    小间距LED显示屏作为种高清晰度、高亮度、色彩还原度的显示设备,广泛应用于室内多种场合。然而,由于其复杂的结构和技术特点,小间距LED显示屏也存在定的故障风险。因此,掌握有效的故障排查
    的头像 发表于 07-07 14:30 1398次阅读
    小间距LED显示屏故障<b class='flag-5'>排查</b><b class='flag-5'>方法</b>

    雅马哈YS/YSM系列贴片机故障排查方法

    雅马哈YS/YSM系列贴片机故障排查方法
    的头像 发表于 09-13 10:05 3496次阅读
    雅马哈YS/YSM系列贴片机故障<b class='flag-5'>排查</b><b class='flag-5'>方法</b>

    光纤收发器的8故障排查

    光纤收发器的8故障排查 光纤收发器是光纤通信中不可或缺的设备之。然而,由于长期使用或其他原因,光纤收发器可能会出现各种故障。为了保证通信的正常进行,我们需要进行故障排查并及时解决问
    的头像 发表于 11-28 15:27 2778次阅读