精华内容
下载资源
问答
  • 深入理解 Linux Load Average

    千次阅读 2020-02-13 12:26:48
    一直不解,为什么io占用较时,系统负载也会变,偶遇此文,终解吾惑。 #1 load average介绍 ##1.1 load average 指标介绍 uptime和top等命令都可以看到load average指标,从左至右三个数字分别表示1分钟、5分钟...

    一直不解,为什么io占用较高时,系统负载也会变高,偶遇此文,终解吾惑。

    #1 load average介绍

    ##1.1 load average 指标介绍

    uptime和top等命令都可以看到load average指标,从左至右三个数字分别表示1分钟、5分钟、15分钟的load average:

    
    uptime
    
    16:04:43 up 20 days, 6:08, 2 users, load average: 0.01, 0.00, 0.00
    
    

    Load average的概念源自UNIX系统,虽然各家的公式不尽相同,但都是用于衡量正在使用CPU的进程数量和正在等待CPU的进程数量,一句话就是runnable processes的数量。所以load average可以作为CPU瓶颈的参考指标,如果大于CPU的数量,说明CPU可能不够用了。

    但是, Linux上不是这样的!

    Linux上的load average除了包括正在使用CPU的进程数量和正在等待CPU的进程数量之外,还包括uninterruptible sleep的进程数量。通常等待IO设备、等待网络的时候,进程会处于uninterruptible sleep状态。Linux设计者的逻辑是,uninterruptible sleep应该都是很短暂的,很快就会恢复运行,所以被等同于runnable。然而uninterruptible sleep即使再短暂也是sleep,何况现实世界中uninterruptible sleep未必很短暂,大量的、或长时间的uninterruptible sleep通常意味着IO设备遇到了瓶颈。众所周知,sleep状态的进程是不需要CPU的,即使所有的CPU都空闲,正在sleep的进程也是运行不了的,所以sleep进程的数量绝对不适合用作衡量CPU负载的指标,Linux把uninterruptible sleep进程算进load average的做法直接颠覆了load average的本来意义。所以在Linux系统上,load average这个指标基本失去了作用,因为你不知道它代表什么意思,当看到load average很高的时候,你不知道是runnable进程太多还是uninterruptible sleep进程太多,也就无法判断是CPU不够用还是IO设备有瓶颈。

    参考资料:https://en.wikipedia.org/wiki/Load_(computing)

    “Most UNIX systems count only processes in the running (on CPU) or runnable (waiting for CPU) states. However, Linux also includes processes in uninterruptible sleep states (usually waiting for disk activity), which can lead to markedly different results if many processes remain blocked in I/O due to a busy or stalled I/O system.“

    ##1.2 load_average 的含义

    ###1.2.1 如何衡量通车大桥的负荷

    判断系统负荷是否过重,必须理解load average的真正含义。下面,我根据 “Understanding Linux CPU Load” 这篇文章,尝试用最通俗的语言,解释这个问题。

    首先,假设最简单的情况,你的电脑只有一个CPU,所有的运算都必须由这个CPU来完成。

    那么,我们不妨把这个CPU想象成一座大桥,桥上只有一根车道,所有车辆都必须从这根车道上通过。(很显然,这座桥只能单向通行。)

    系统负荷为0,意味着大桥上一辆车也没有。

    图片1

    系统负荷为0.5,意味着大桥一半的路段有车。

    图片 2

    系统负荷为1.0,意味着大桥的所有路段都有车,也就是说大桥已经"满"了。但是必须注意的是,直到此时大桥还是能顺畅通行的。

    图片 3

    桥上在通车的时候, 不光桥上的车影响通车的效率, 后面排队等着还没有上桥的也对桥的拥挤程度有贡献, 因此我们有必要考虑这点, 如果把等待的那些车也算到负载中去, 那么负荷就会 > 1.0.

    系统负荷为1.7,意味着车辆太多了,大桥已经被占满了(100%),后面等着上桥的车辆为桥面车辆的70%。以此类推,系统负荷2.0,意味着等待上桥的车辆与桥面的车辆一样多;系统负荷3.0,意味着等待上桥的车辆是桥面车辆的2倍。总之,当系统负荷大于1,后面的车辆就必须等待了;系统负荷越大,过桥就必须等得越久。

    图片 4

    ###1.2.2 类比CPU的系统负荷

    CPU的系统负荷,基本上等同于上面的类比。大桥的通行能力,就是CPU的最大工作量;桥梁上的车辆,就是一个个等待CPU处理的进程(process)。

    如果CPU每分钟最多处理100个进程,那么系统负荷0.2,意味着CPU在这1分钟里只处理20个进程;系统负荷1.0,意味着CPU在这1分钟里正好处理100个进程;系统负荷1.7,意味着除了CPU正在处理的100个进程以外,还有70个进程正排队等着CPU处理。

    为了电脑顺畅运行,系统负荷最好不要超过1.0,这样就没有进程需要等待了,所有进程都能第一时间得到处理。很显然,1.0是一个关键值,超过这个值,系统就不在最佳状态了,你要动手干预了。

    ###1.2.3 系统负荷的经验法则

    1.0是系统负荷的理想值吗?

    不一定,系统管理员往往会留一点余地,当这个值达到0.7,就应当引起注意了。经验法则是这样的:

    当系统负荷持续大于0.7,你必须开始调查了,问题出在哪里,防止情况恶化。

    当系统负荷持续大于1.0,你必须动手寻找解决办法,把这个值降下来。

    当系统负荷达到5.0,就表明你的系统有很严重的问题,长时间没有响应,或者接近死机了。你不应该让系统达到这个值。

    ###1.2.4 多处理器的情形

    上面,我们假设你的电脑只有1个CPU。如果你的电脑装了2个CPU,会发生什么情况呢?

    2个CPU,意味着电脑的处理能力翻了一倍,能够同时处理的进程数量也翻了一倍。

    还是用大桥来类比,两个CPU就意味着大桥有两根车道了,通车能力翻倍了。

    图片 6

    所以,2个CPU表明系统负荷可以达到2.0,此时每个CPU都达到100%的工作量。推广开来,n个CPU的电脑,可接受的系统负荷最大为n.0。

    ###1.2.5 多核处理器的情形

    芯片厂商往往在一个CPU内部,包含多个CPU核心,这被称为多核CPU。

    在系统负荷方面,多核CPU与多CPU效果类似,所以考虑系统负荷的时候,必须考虑这台电脑有几个CPU、每个CPU有几个核心。然后,把系统负荷除以总的核心数,只要每个核心的负荷不超过1.0,就表明电脑正常运行。

    怎么知道电脑有多少个CPU核心呢?

    "cat /proc/cpuinfo"命令,可以查看CPU信息。"grep -c ‘model name’ /proc/cpuinfo"命令,直接返回CPU的总核心数。

    -###1.2.6 最佳观察时长

    最后一个问题,"load average"一共返回三个平均值----1分钟系统负荷、5分钟系统负荷,15分钟系统负荷,----应该参考哪个值?

    如果只有1分钟的系统负荷大于1.0,其他两个时间段都小于1.0,这表明只是暂时现象,问题不大。

    如果15分钟内,平均系统负荷大于1.0(调整CPU核心数之后),表明问题持续存在,不是暂时现象。所以,你应该主要观察"15分钟系统负荷",将它作为电脑正常运行的指标。

    #2 Loadavg分析

    ##2.1 读取 loadavg 的接口 /proc/loadavg

    在内核中 /proc/loadavg 是通过 loadavg_proc_show 来读取相应数据,下面首先来看一下load_read_proc的实现:

    # https://elixir.bootlin.com/linux/v5.2.13/source/kernel/sched/loadavg.c#L64
    
    /**
     * get_avenrun - get the load average array
     * @loads: pointer to dest load array
     * @offset: offset to add
     * @shift: shift count to shift the result left
     *
     * These values are estimates at best, so no need for locking.
     */
    void get_avenrun(unsigned long *loads, unsigned long offset, int shift)
    {
        loads[0] = (avenrun[0] + offset) << shift;
        loads[1] = (avenrun[1] + offset) << shift;
        loads[2] = (avenrun[2] + offset) << shift;
    }
    
    # http://elixir.bootlin.com/linux/v5.2.13/source/fs/proc/loadavg.c#13
    static int loadavg_proc_show(struct seq_file *m, void *v)
    {
        unsigned long avnrun[3];
    
        get_avenrun(avnrun, FIXED_1/200, 0);
    
        seq_printf(m, "%lu.%02lu %lu.%02lu %lu.%02lu %ld/%d %d\n",
            LOAD_INT(avnrun[0]), LOAD_FRAC(avnrun[0]),
            LOAD_INT(avnrun[1]), LOAD_FRAC(avnrun[1]),
            LOAD_INT(avnrun[2]), LOAD_FRAC(avnrun[2]),
            nr_running(), nr_threads,
            idr_get_cursor(&task_active_pid_ns(current)->idr) - 1);
        return 0;
    }
    
    

    几个宏的定义如下 :

    
    # https://elixir.bootlin.com/linux/v5.2.13/source/include/linux/sched/loadavg.h#L43
    
    
    
    #define FSHIFT 11 /* nr of bits of precision */
    
    #define FIXED_1 (1<<FSHIFT) /* 1.0 as fixed-point */
    
    #define LOAD_FREQ (5*HZ+1) /* 5 sec intervals */
    
    #define EXP_1 1884 /* 1/exp(5sec/1min) as fixed-point */
    
    #define EXP_5 2014 /* 1/exp(5sec/5min) */
    
    #define EXP_15 2037 /* 1/exp(5sec/15min) */
    
    
    
    #define LOAD_INT(x) ((x) >> FSHIFT)
    
    #define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)
    
    

    根据输出格式,LOAD_INT对应计算的是load的整数部分,LOAD_FRAC计算的是load的小数部分。

    将a=avenrun[0] + (FIXED_1/200)带入整数部分和小数部分计算可得:

    $$avnrun_i = (avnrun_i + \frac{FIXED_1}{200}) <<11

    = (avnrun_i+ 1>>11/200) <<11$$

    = \frac{avnrun_i + \frac{2{11}}{200}}{2{11}}$$

    
    LOAD_INT(a) = avnrun_i + \frac{2^{11}}{200}
    
    LOAD_FRAC(a) = ((avenrun[0]%(2^11) + 2^11/200) * 100) / (2^11)
                 = (((avenrun[0]%(2^11)) * 100 + 2^10) / (2^11)
                 = ((avenrun[0]%(2^11) * 100) / (2^11) + ½
    

    由上述计算结果可以看出,FIXED_1/200在这里是用于小数部分第三位的四舍五入,由于小数部分只取前两位,第三位如果大于5,则进一位,否则直接舍去。

    临时变量a/b/c的低11位存放的为load的小数部分值,第11位开始的高位存放的为load整数部分。

    因此可以得到a=load(1min) * 2^11

    因此有: load(1min) * 2^11 = avenrun[0] + 2^11 / 200

    进而推导出: load(1min)=avenrun[0]/(2^11) + 1/200

    忽略用于小数部分第3位四舍五入的1/200,可以得到load(1min)=avenrun[0] / 2^11,即:

    avenrun[0] = load(1min) * 2^11

    avenrun是个陌生的量,这个变量是如何计算的,和系统运行进程、cpu之间的关系如何,在第二阶段进行分析。

    ##2.2 avenrun 如何表示CPU 负载

    内核将 load的计算和load的查看进行了分离,avenrun就是用于连接load计算和load查看的桥梁。
    下面开始分析通过avenrun进一步分析系统load的计算。

    ###2.2.1 avenrun 的更新

    avenrun 数组是在 calc_global_load 中进行更新, 在系统更新了 calc_load_update 过了 10 个 jiffies 之后, 会在 do_timer 更新 jiffies 之后, 直接调用 calc_global_load 更新 avenrun 数组

    
    do_timer
    
        -=> calc_global_load
    
    # https://elixir.bootlin.com/linux/v5.2.13/source/kernel/sched/loadavg.c#L337
    /*
    
     * calc_load - update the avenrun load estimates 10 ticks after the
    
     * CPUs have updated calc_load_tasks.
    
     *
    
     * Called from the global timer code.
    
     */
    
    void calc_global_load(unsigned long ticks)
    
    {
    
        unsigned long sample_window;
    
        long active, delta;
    
    
    
        sample_window = READ_ONCE(calc_load_update);
    
        if (time_before(jiffies, sample_window + 10))
    
            return;
    
    
    
        /*
    
         * Fold the 'old' NO_HZ-delta to include all NO_HZ CPUs.
    
         */
    
        delta = calc_load_nohz_fold();
    
        if (delta)
    
            atomic_long_add(delta, &calc_load_tasks);
    
    
    
        active = atomic_long_read(&calc_load_tasks);
    
        active = active > 0 ? active * FIXED_1 : 0;
    
    
    
        avenrun[0] = calc_load(avenrun[0], EXP_1, active);
    
        avenrun[1] = calc_load(avenrun[1], EXP_5, active);
    
        avenrun[2] = calc_load(avenrun[2], EXP_15, active);
    
    
    
        WRITE_ONCE(calc_load_update, sample_window + LOAD_FREQ);
    
    
    
        /*
    
         * In case we went to NO_HZ for multiple LOAD_FREQ intervals
    
         * catch up in bulk.
    
         */
    
        calc_global_nohz();
    
    }
    
    

    calc_load_tasks 可以理解为当前系统中 RUNNING(R状态)进程和 uninterruptible(D状态)进程的总数目.

    active_tasks为系统中当前贡献load的task数nr_active乘于FIXED_1,用于计算avenrun

    avenrun 的计算方法 calc_load 如下所示:

    
    # https://elixir.bootlin.com/linux/v5.2.13/source/include/linux/sched/loadavg.h#L19
    
    /*
    
     * a1 = a0 * e + a * (1 - e)
    
     */
    
    static inline unsigned long
    
    calc_load(unsigned long load, unsigned long exp, unsigned long active)
    
    {
    
        unsigned long newload;
    
    
    
        newload = load * exp + active * (FIXED_1 - exp);
    
        if (active >= load)
    
            newload += FIXED_1-1;
    
    
    
        return newload / FIXED_1;
    
    }
    
    

    用avenrun(t-1)和avenrun(t)分别表示上一次计算的avenrun和本次计算的avenrun,则根据CALC_LOAD宏可以得到如下计算:

    avenrun(t)=(avenrun(t-1) * EXP_N + nr_active * FIXED_1*(FIXED_1 – EXP_N)) / FIXED_1

          = avenrun(t-1) + (nr_active*FIXED_1 – avenrun(t-1)) * (FIXED_1 -EXP_N) / FIXED_1
    

    推导出:

    avenrun(t) – avenrun(t-1) = (nr_active*FIXED_1 – avenrun(t-1)) * (FIXED_1 – EXP_N) / FIXED_1

    将第一阶段推导的结果代入上式,可得:

    (load(t) – load(t-1)) * FIXED_1 = (nr_active – load(t-1)) * (FIXED_1 – EXP_N)

    进一步得到nr_active变化和load变化之间的关系式:

    load(t) – load(t-1) = (nr_active – load(t-1)) * (FIXED_1 – EXP_N) / FIXED_1

    这个式子可以反映的内容包含如下两点:

    1)当nr_active为常数时,load会不断的趋近于nr_active,趋近速率由快逐渐变缓

    2)nr_active的变化反映在load的变化上是被降级了的,系统突然间增加10个进程,

    1分钟load的变化每次只能够有不到1的增加(这个也就是权重的的分配)。

    另外也可以通过将式子简化为:

    load(t)= load(t-1) * EXP_N / FIXED_1 + nr_active * (1 - EXP_N/FIXED_1)

    这样可以更加直观的看出nr_active和历史load在当前load中的权重关系 (多谢任震宇大师的指出)

    
    #define EXP_1 1884 /* 1/exp(5sec/1min) as fixed-point */ 
    
    #define EXP_5 2014 /* 1/exp(5sec/5min) */ 
    
    #define EXP_15 2037 /* 1/exp(5sec/15min) */
    
    

    1分钟、5分钟、15分钟对应的EXP_N值如上,随着EXP_N的增大,(FIXED_1 – EXP_N)/FIXED_1值就越小,

    这样nr_active的变化对整体load带来的影响就越小。对于一个nr_active波动较小的系统,load会

    不断的趋近于nr_active,最开始趋近比较快,随着相差值变小,趋近慢慢变缓,越接近时越缓慢,并最

    终达到nr_active。如下图所示:

    文件:load 1515.jpg(无图)

    也因此得到一个结论,load直接反应的是系统中的nr_active。 那么nr_active又包含哪些? 如何去计算

    当前系统中的nr_active? 这些就涉及到了nr_active的采样。

    ###2.2.2 calc_load_tasks 的更新


    calc_load_tasks 常规情况下在 tick 中进行更新.

    this_rq->calc_load_active 记录了当前 RQ 上 RUNNING(R状态)线程和 uninterruptible(D状态)线程的总数.

    delta 为上次更新到现在 this_rq 上 R+D 状态进程的增量情况.

    calc_load_tasks 则保存了当前系统中进程 R+D 状态进程的总数目.

    LOAD_FREQ 被定义成 5HZ+1(5S 之后), 是更新 this_rq->calc_load_active 和 全局的 calc_load_tasks 的时间间隔, 每 LOAD_FREQ 才会更新一次.

    this_rq->calc_load_update 总表示当前RQ 上下次执行 calc_global_load_tick 时可以进行更新的时间

    在 calc_global_load_tick 中

    1. 先检查 calc_load_update 到期没,

    2. 到期后,

    先更新了 this_rq->calc_load_active
    
    接着更新了全局的 calc_load_tasks.
    
    最后设置 this_rq->calc_load_update 为 LOAD_FREQ(5S) 之后.
    

    因此每隔 LOAD_FREQ的时间, 系统在calc_global_load_tick 中基于 this_rq->calc_load_active, 更新 全局的calc_load_tasks.

    
    # https://elixir.bootlin.com/linux/v5.2.13/source/kernel/sched/loadavg.c#L79
    
    static long calc_load_fold_active(struct rq *this_rq)
    
    {
    
            long nr_active, delta = 0;
    
     
    
            nr_active = this_rq->nr_running;
    
            nr_active += (long) this_rq->nr_uninterruptible;
    
     
    
            if (nr_active != this_rq->calc_load_active) {
    
                    delta = nr_active - this_rq->calc_load_active;
    
                    this_rq->calc_load_active = nr_active;
    
            }
    
     
    
            return delta;
    
    }
    
    
    
    # https://elixir.bootlin.com/linux/v5.2.13/source/kernel/sched/loadavg.c#L369
    
    /*
    
     * Called from scheduler_tick() to periodically update this CPU's
    
     * active count.
    
     */
    
    void calc_global_load_tick(struct rq *this_rq)
    
    {
    
        long delta;
    
    
    
        if (time_before(jiffies, this_rq->calc_load_update))
    
            return;
    
    
    
        delta = calc_load_fold_active(this_rq, 0);
    
        if (delta)
    
            atomic_long_add(delta, &calc_load_tasks);
    
    
    
        this_rq->calc_load_update += LOAD_FREQ;
    
    }
    
    

    而 avenrun 则在 calc_load_update 更新 10 ticks 之后通过 calc_global_load 更新.

    #3 参考资料

    https://www.cnblogs.com/qqmomery/p/6267429.html

    http://linuxperf.com/?p=176

    https://scoutapm.com/blog/understanding-load-averages

    http://www.ruanyifeng.com/blog/2011/07/linux_load_average_explained.html

    http://www.blogjava.net/cenwenchu/archive/2008/06/30/211712.html

    https://www.cnblogs.com/qqmomery/p/6267429.html

    展开全文
  • 判断Linux load的值是否过

    千次阅读 2017-07-01 16:04:00
    接触过和使用过unix或linux的朋友,都知道如何查看Unix/Linux load的值,这边我也重复一下查看load的方法:[root@www.linuxidc.com ~]# uptime13:33:37 up 7 days, 1:52, 1 user, load average: 4.15, ...

    接触过和使用过unix或linux的朋友,都知道如何查看Unix/Linux load的值,这边我也重复一下查看load的方法:

    [root@www.linuxidc.com ~]# uptime13:33:37 up 7 days, 1:52, 1 user, load average: 4.15, 2.00, 3.14[root@www.linuxidc.com ~]# w13:35:35 up 1 days, 1:54, 1 user, load average: 0.00, 0.00, 0.00USER TTY FROM LOGIN@ IDLE JCPU PCPU WHATroot pts/1 192.168.2.2 13:33 0.00s 0.02s 0.00s w

    load average 后面三个值代表系统在1分钟、5分钟和15分钟的负载情况,都知道数字越高表示系统负载越大,第一直觉就是这个系统不行了。load average 是0的时候都认为他很低,10的时候就觉得高,20就不用讲了!但是除了这两种极端的情况之外,那什么时候是这两个值的临界点?当别人问起我这个问题的时候,我也不知道如何回答,在我大脑里就根本就没有考虑过。困扰了我很久,我觉得要搞明白他!

    先从linux的kernel的源码开始吧!在linux 2.6.36版本中有这样一段代码:

    /*** spu_calc_load – update the avenrun load estimates.** No locking against reading these values from userspace, as for* the CPU loadavg code.*/static void spu_calc_load(void){unsigned long active_tasks; /* fixed-point */active_tasks = count_active_contexts() * FIXED_1;CALC_LOAD(spu_avenrun[0], EXP_1, active_tasks);CALC_LOAD(spu_avenrun[1], EXP_5, active_tasks);CALC_LOAD(spu_avenrun[2], EXP_15, active_tasks);}CALC_LOAD是这样定义:#define LOAD_FREQ (5*HZ+1) /* 5 sec intervals */#define EXP_1 1884 /* 1/exp(5sec/1min) as fixed-point */#define EXP_5 2014 /* 1/exp(5sec/5min) */#define EXP_15 2037 /* 1/exp(5sec/15min) */#define CALC_LOAD(load,exp,n) \load *= exp; \load += n*(FIXED_1-exp); \load >>= FSHIFT;

    从这里我们能看到取负载值的最小周期5秒,根据代码中定义我们知道

    什么是load?

    load的就是一定时间内计算机有多少个active_tasks,也就是说是计算机的任务执行队列的长度,cpu计算的队列。

    load多少是正常?

    既然load是cpu计算的队列,那就应该和cpu个处理方式和cpu的个数有关系。所以我个人认为应该按系统识别的cpu个数来确定load的临界值,系统识别为8个cpu,那么load为8就是临界点,高与8就属于over load了。

    什么叫系统识别cpu个数?

    我是这样认为的,这里涉及到cpu物理个数和超线程技术的问题。个人认为4个物理cpu和2个双核是不能够等同的,当然这是物理层面的事了!在系统里识别的都是4个CPU.所以应该要以系统识别的为准。毕竟是系统去支配他的使用。

    CPU高不等同于load高

    在Unix/Linux可能经常会遇到cpu的使用率为100%,但是load却不高!这是为什么呢?因为几乎所有的任务和会和CPU进行交互,但是由于各个设备的使用频率不同,造成了不能同步进行的问题。比如说,当对硬盘进行读写的时候,出现IO的等待时候,事实上cpu已经被切换到别的进程上了。该任务就处于等待状态,当这样的任务过多,导致队列长度过大,这样就体现到负载过大了,但实际是此时cpu被分配去干执行别的任务或空闲,因此CPU高不等同于load高,load高也不能于cpu高。 


    展开全文
  • Linux排查Load问题

    万次阅读 2018-11-17 14:41:32
    情况1:CPULoad高 通过top命令查找占用CPU最高的进程PID; 通过top -Hp PID查找占用CPU最高的线程TID; 对于java程序,使用jstack打印线程堆栈信息; 通过printf %x tid打印出最消耗CPU线程的十六进制; 在...

    情况1:CPU高、Load高

    1. 通过top命令查找占用CPU最高的进程PID;
    2. 通过top -Hp PID查找占用CPU最高的线程TID;
    3. 对于java程序,使用jstack打印线程堆栈信息;
    4. 通过printf %x tid打印出最消耗CPU线程的十六进制;
    5. 在堆栈信息中查看该线程的堆栈信息;

    情况2:CPU低、Load高

    1. 通过top命令查看CPU等待IO时间,即%wa;
    2. 通过iostat -d -x -m 1 10查看磁盘IO情况;(安装命令 yum install -y sysstat)
    3. 通过sar -n DEV 1 10查看网络IO情况;
    4. 通过如下命令查找占用IO的程序;
    ps -e -L h o state,cmd  | awk '{if($1=="R"||$1=="D"){print $0}}' | sort | uniq -c | sort -k 1nr
    sar 5 6   //每隔5s 输出6次后退出

     

    16时13分01秒     CPU     %user     %nice   %system   %iowait    %steal     %idle
    16时13分06秒     all      9.15      0.00     48.19      0.05      0.00     42.61
    16时13分11秒     all      2.13      0.00      8.76      0.08      0.00     89.03
    16时13分16秒     all      2.13      0.00     11.41      0.03      0.00     86.44
    16时13分21秒     all      2.20      0.00     10.61      0.05      0.00     87.14
    16时13分26秒     all      2.48      0.00     10.44      0.08      0.00     87.00
    16时13分31秒     all      2.40      0.00     10.51      0.05      0.00     87.00
    

    注:

    CPU:all 表示统计信息为所有 CPU 的平均值。

    %user:显示在用户级别(application)运行使用 CPU 总时间的百分比。

    %nice:显示在用户级别,用于nice操作,所占用 CPU 总时间的百分比。

    %system:在核心级别(kernel)运行所使用 CPU 总时间的百分比。

    %iowait:显示用于等待I/O操作占用 CPU 总时间的百分比。

    %steal:管理程序(hypervisor)为另一个虚拟进程提供服务而等待虚拟 CPU 的百分比。

    %idle:显示 CPU 空闲时间占用 CPU 总时间的百分比。

    排查实例

    一、vmstat选项

    -a    显示活跃内存(active)和非活跃内存(inact)
    -f    显示从系统启动至今的fork数量 
    -m    显示slabinfo
    -s    静态显示内存相关信息

    首先运行一个默认命令, 根据输出结果,解释下各个字段的含义,有助于下面的分析。

    [root@master ~]# vmstat 
    procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
     r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
     1  0      0 431340  44840 211744    0    0     5     2  149    9  2  4 95  0  0    
    
    [root@minion ~]# vmstat -a
    procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
     r  b   swpd   free  inact active   si   so    bi    bo   in   cs us sy id wa st
     1  0      0 757496  64916  83772    0    0    85     7   56   42  1  3 96  0  0    


    各个字段对应的项含义如下 
    procs

    - r    正在等待运行的进程数
    - b    在uninterruptible 睡眠中的进程数

    memory

    - swpd    以使用的swap空间
    - free    剩余的物理内存
    - buff    buffer
    - cache    cache
    - inact    非活动的内数量(-a选项)
    - active    活动的内存的数量(-a选项)

    swap 
    - si 从磁盘交换的内存大小 
    - so 交换到磁盘的内存大小

    io

    - bi    从块设备接收的块(block/s)
    - bo    发送给块设备的块(block/s).如果这个值长期不为0,说明内存可能有问题,因为没有使用到缓存(当然,不排除直接I/O的情况,但是一般很少有直接I/O的)

    system

    - in     每秒的中断次数,包括时钟中断
    - cs    进程上下文切换次数

    cpu

    - us    用户进程占用CPU时间比例
    - sy    系统占用CPU时间比例
    - id    CPU空闲时间比
    - wa    IO等待时间比(IO等待高时,可能是磁盘性能有问题了)
    - st    steal time

    二、CPU篇
    2.1 监控指标
    CPU利用率。根据经验来看,用户空间进程占用CPU比例在 65-70%之间,内核(系统)CPU比例在30%-35%之间,空闲比例在0%-5%之间。一般不能超过这个比例,超过这个比例,系统性能就会降低,平均负载升高,这点将会在下面的测试中看到。
    进程上下文切换。上下文切换和CPU利用率应该联系起来,如果CPU利用率低,那么上下文切换稍高点也能接受。上下文切换也是需要消耗CPU资源的,频繁的切换必将使得CPU利用率升高。
    运行队列中等待运行的进程数。每个CPU核心中等待处理的进程数不应该超过3个线程/进程。如4核心的机器,那么队列的最大值应该不超过12个。
    平均负载。平均负载值是平均每核心CPU的负载应该控制在0.7。最好不要超过1.

      一般,我是使用top命令和vmstat命令一起看,top命令可以看到整体情况,也可以看到每个任务消耗资源的情况。使用vmstat命令查看队列中的任务书、进程上下文切换。

    下面是一个CPU密集型程序,采用多线程(20个线程)去循环将一个全局变量+1. 
    这个程序如下

    #!/usr/bin/python
    
    import threading
    
    count = 0
    
    class Test(threading.Thread):
        def __init__(self):
            threading.Thread.__init__(self)
    
        def run(self):
            global count
            for i in xrange(1,100000000):    #100000000
                count += 1
            print count
    if __name__ == '__main__':
        threads = []
        for i in range(10):
            thread = Test()
            threads.append(thread)
            thread.start()
        for thread in threads:
            thread.join()
        print count


    2.2 程序运行前
      我在程序运行前使用top命令和vmstat命令查看相关报告

    vmstat报告

    [root@master ~]# vmstat 2 10
    procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
     r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
     0  0      0 432696  43672 211724    0    0     6     2  148  715  2  4 94  0  0    
     0  0      0 432688  43672 211724    0    0     0     0   20   17  0  0 100  0  0   
     0  0      0 432688  43672 211724    0    0     0     0   16   17  0  0 100  0  0   
     0  0      0 432432  43672 211724    0    0     0     0   54   43  0  1 99  0  0    
     0  0      0 432400  43672 211724    0    0     0     0   38   37  0  0 100  0  0   
     0  0      0 432376  43672 211724    0    0     0     0   88   65  0  1 99  0  0    
     0  0      0 432120  43672 211724    0    0     0     0   49   35  0  1 99  0  0    
     0  0      0 432152  43672 211724    0    0     0     0   31   28  0  0 99  0  0    
     0  0      0 432152  43672 211724    0    0     0     0   29   26  0  0 100  0  0   
     0  0      0 432152  43672 211724    0    0     0     0   15   16  0  0 100  0  0   

    top报告
     

    [root@master ~]# top
    top - 12:11:37 up  7:07,  3 users,  load average: 0.00, 0.00, 0.02
    Tasks: 114 total,   1 running, 113 sleeping,   0 stopped,   0 zombie
    Cpu0  :  1.8%us,  3.3%sy,  0.0%ni, 94.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
    Cpu1  :  1.3%us,  3.8%sy,  0.0%ni, 94.8%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
    Mem:   1004412k total,   573856k used,   430556k free,    45160k buffers
    Swap:  2047992k total,        0k used,  2047992k free,   211748k cached

     根据top报告和vmstat报告,我们完全可以得出结论——系统性能良好。因为各个指标的值都不高

    2.3 程序运行时
    vmstat报告

    [root@master ~]# vmstat 2 10
    procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
     r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
    21  0      0 423072  43640 211724    0    0     6     2  142  506  2  4 95  0  0    
    20  0      0 423064  43640 211724    0    0     0     0 2085 78125 26 73  1  0  0   
    20  0      0 423064  43640 211724    0    0     0     0 2038 79752 24 74  1  0  0   
    20  0      0 423064  43640 211724    0    0     0     0 2057 78022 25 74  1  0  0   
    20  0      0 423064  43640 211724    0    0     0     0 2045 85145 25 73  2  0  0   
    20  0      0 423032  43640 211724    0    0     0    12 2002 68602 25 73  2  0  0   
    20  0      0 422908  43640 211724    0    0     0     0 2065 79101 25 73  1  0  0   
    20  0      0 422908  43640 211724    0    0     0     0 2048 78424 26 73  1  0  0   
    10  0      0 422940  43640 211724    0    0     0     0 2039 69779 22 76  2  0  0   
    21  0      0 422940  43640 211724    0    0     0     0 2050 81712 26 73  2  0  0   



    top报告

    [root@master ~]# top
    top - 10:55:10 up  5:51,  3 users,  load average: 15.01, 11.58, 6.21
    Tasks: 115 total,   1 running, 114 sleeping,   0 stopped,   0 zombie
    Cpu0  : 27.8%us, 72.2%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
    Cpu1  : 22.2%us, 77.8%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
    Mem:   1004412k total,   581836k used,   422576k free,    43656k buffers
    Swap:  2047992k total,        0k used,  2047992k free,   211724k cached

     运行时的情况看起来就十分不好了。我重点关注了这几个值: 
    top报告分析 
    - load average: 15.01, 11.58, 6.21 
    - %sys: 都已经达到了70%以上 
    - id% 都是 0

    vmstat报告分析 
    - r 运行队列中等待的线程/进程基本上都是20左右 
    - cs 上下文切换每秒80000次左右

    从上述分析中可以看出,系统系能已经很差了。这里我尝试做一个分析,为什么系统占用CPU的利用率这么高?我认为是程序运行时的进程上下文频繁切换所导致的,这是因为进程/线程的调度室通过内核子系统进程调度程序来调度的,频繁的切换说明进程调度程序也是十分频繁的的占用CPU,因此导致系统占用CPU的时间很高;此外,系统调用也是耗费了一部分时间的。因此系统占用CPU的比例很高,而用户空间进程占有CPU的比例相对就低了很多。系统就是给用户提供服务的,如果大部分资源都被系统给占用,那这个用户还能做什么工作呢?

    补充top 字段含义

    %hi , IRQ。如果这个值不均衡,则说明没有设置中断均衡。设置方法可参考我之前的文章多队列网卡中断均衡

    - %si    soft IRQ,即软中断
    - PR     优先级
    - NI      nice值
    - VIRT    virtual image(kb)
    - RES    Resident size。已使用的非swap物理内存
    - SHR    共享内存大小(kb)
    - %CPU    占总CPU时间的百分比。这个值是和上次更新至现在的CPU使用率。如top命令3秒更新一次数据,那这个值就是这个3秒内的CPU使用率
    - %MEM  任务当

    相关工具使用介绍:

    sar用法详解 :Linux的sar命令详解

    iostat用法详解:Linux IO实时监控iostat命令详解

    vmstat用法详解:Linux vmstat命令实战详解

    展开全文
  • linux load average负载详细解释

    千次阅读 2018-12-21 08:57:59
    转载至linux load average负载详细解释 一、load average top命令中load average显示的是最近1分钟、5分钟和15分钟的系统平均负载。系统平均负载表示  系统平均负载被定义为在特定时间间隔内运行队列中(在CPU上运行...

    转载至linux load average负载详细解释
    一、load average
    top命令中load average显示的是最近1分钟、5分钟和15分钟的系统平均负载。系统平均负载表示
      系统平均负载被定义为在特定时间间隔内运行队列中(在CPU上运行或者等待运行多少进程)的平均进程数。如果一个进程满足以下条件则其就会位于运行队列中:
      - 它没有在等待I/O操作的结果
      - 它没有主动进入等待状态(也就是没有调用’wait’)
      - 没有被停止(例如:等待终止)
      Update:在Linux中,进程分为三种状态,一种是阻塞的进程blocked process,一种是可运行的进程runnable process,另外就是正在运行的进程running process。当进程阻塞时,进程会等待I/O设备的数据或者系统调用。
      进程可运行状态时,它处在一个运行队列run queue中,与其他可运行进程争夺CPU时间。 系统的load是指正在运行running one和准备好运行runnable one的进程的总数。比如现在系统有2个正在运行的进程,3个可运行进程,那么系统的load就是5。load average就是一定时间内的load数量。
      一般来说只要每个CPU的当前活动进程数不大于3那么系统的性能就是良好的,如果每个CPU的任务数大于5,那么就表示这台机器的性能有严重问题。对于上面的例子来说,假设系统有两个CPU,那么其每个CPU的当前任务数为:8.13/2=4.065。这表示该系统的性能是可以接受的。
      在Linux系统中,uptime、w、top等命令都会有系统平均负载load average的输出
      load average: 0.09, 0.05, 0.01
      很多人会这样理解负载均值:三个数分别代表不同时间段的系统平均负载(一分钟、五 分钟、以及十五分钟),它们的数字当然是越小越好。数字越高,说明服务器的负载越 大,这也可能是服务器出现某种问题的信号。
      而事实不完全如此,是什么因素构成了负载均值的大小,以及如何区分它们目前的状况是 “好”还是“糟糕”?什么时候应该注意哪些不正常的数值?
      回答这些问题之前,首先需要了解下这些数值背后的些知识。我们先用最简单的例子说明, 一台只配备一块单核处理器的服务器。
      行车过桥
      一只单核的处理器可以形象得比喻成一条单车道。设想下,你现在需要收取这条道路的过桥 费 — 忙于处理那些将要过桥的车辆。你首先当然需要了解些信息,例如车辆的载重、以及 还有多少车辆正在等待过桥。如果前面没有车辆在等待,那么你可以告诉后面的司机通过。 如果车辆众多,那么需要告知他们可能需要稍等一会。
      因此,需要些特定的代号表示目前的车流情况,例如:
      0.00 表示目前桥面上没有任何的车流。 实际上这种情况与 0.00 和 1.00 之间是相同的,总而言之很通畅,过往的车辆可以丝毫不用等待的通过。
      1.00 表示刚好是在这座桥的承受范围内。 这种情况不算糟糕,只是车流会有些堵,不过这种情况可能会造成交通越来越慢。
      超过 1.00,那么说明这座桥已经超出负荷,交通严重的拥堵。 那么情况有多糟糕? 例如 2.00 的情况说明车流已经超出了桥所能承受的一倍,那么将有多余过桥一倍的车辆正在焦急的等待。3.00 的话情况就更不妙了,说明这座桥基本上已经快承受不了,还有超出桥负载两倍多的车辆正在等待。
      上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程 的实际时间。Unix 系统定义的进程运行时长为所有处理器内核的处理时间加上线程 在队列中等待的时间。
      和收过桥费的管理员一样,你当然希望你的汽车(操作)不会被焦急的等待。所以,理想状态 下,都希望负载平均值小于 1.00 。当然不排除部分峰值会超过 1.00,但长此以往保持这 个状态,就说明会有问题,这时候你应该会很焦急。
      “所以你说的理想负荷为 1.00 ?”
      嗯,这种情况其实并不完全正确。负荷 1.00 说明系统已经没有剩余的资源了。在实际情况中 ,有经验的系统管理员都会将这条线划在 0.70:
      “需要进行调查法则”: 如果长期你的系统负载在 0.70 上下,那么你需要在事情变得更糟糕之前,花些时间了解其原因。
      “现在就要修复法则”:1.00 。 如果你的服务器系统负载长期徘徊于 1.00,那么就应该马上解决这个问题。否则,你将半夜接到你上司的电话,这可不是件令人愉快的事情。
      “凌晨三点半锻炼身体法则”:5.00。 如果你的服务器负载超过了 5.00 这个数字,那么你将失去你的睡眠,还得在会议中说明这情况发生的原因,总之千万不要让它发生。
      那么多个处理器呢?我的均值是 3.00,但是系统运行正常!
      哇喔,你有四个处理器的主机?那么它的负载均值在 3.00 是很正常的。
      在多处理器系统中,负载均值是基于内核的数量决定的。以 100% 负载计算,1.00 表示单个处理器,而 2.00 则说明有两个双处理器,那么 4.00 就说明主机具有四个处理器。
      回到我们上面有关车辆过桥的比喻。1.00 我说过是“一条单车道的道路”。那么在单车道 1.00 情况中,说明这桥梁已经被车塞满了。而在双处理器系统中,这意味着多出了一倍的 负载,也就是说还有 50% 的剩余系统资源 — 因为还有另外条车道可以通行。
      所以,单处理器已经在负载的情况下,双处理器的负载满额的情况是 2.00,它还有一倍的资源可以利用。
      多核与多处理器
      先脱离下主题,我们来讨论下多核心处理器与多处理器的区别。从性能的角度上理解,一台主 机拥有多核心的处理器与另台拥有同样数目的处理性能基本上可以认为是相差无几。当然实际 情况会复杂得多,不同数量的缓存、处理器的频率等因素都可能造成性能的差异。
      但即便这些因素造成的实际性能稍有不同,其实系统还是以处理器的核心数量计算负载均值 。这使我们有了两个新的法则:
      “有多少核心即为有多少负荷”法则: 在多核处理中,你的系统均值不应该高于处理器核心的总数量。
      “核心的核心”法则: 核心分布在分别几个单个物理处理中并不重要,其实两颗四核的处理器 等于 四个双核处理器 等于 八个单处理器。所以,它应该有八个处理器内核。
      审视我们自己
      让我们再来看看 uptime 的输出
      ~ $ uptime
      23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36
      这是个双核处理器,从结果也说明有很多的空闲资源。实际情况是即便它的峰值会到 1.7,我也从来没有考虑过它的负载问题。
      那么,怎么会有三个数字的确让人困扰。我们知道,0.65、0.42、0.36 分别说明上一分钟、最后五分钟以及最后十五分钟的系统负载均值。那么这又带来了一个问题:
      我们以哪个数字为准?一分钟?五分钟?还是十五分钟?
      其实对于这些数字我们已经谈论了很多,我认为你应该着眼于五分钟或者十五分钟的平均数 值。坦白讲,如果前一分钟的负载情况是 1.00,那么仍可以说明认定服务器情况还是正常的。 但是如果十五分钟的数值仍然保持在 1.00,那么就值得注意了(根据我的经验,这时候你应 该增加的处理器数量了)。
      那么我如何得知我的系统装备了多少核心的处理器?
      在 Linux 下,可以使用
      cat /proc/cpuinfo
      获取你系统上的每个处理器的信息。如果你只想得到数字,那么就使用下面的命令:
      grep 'model name' /proc/cpuinfo | wc -l
    二、top
    转载至linux top命令详解
           在理解了load average各个值的含义后,可以用top命令来了解系统的整理状态,关注重量变量的时刻变化。为此还需了解以下这些变量。
    下面详细介绍它的使用方法。
    top - 01:06:48 up 1:22, 1 user, load average: 0.06, 0.60, 0.48
    Tasks: 29 total, 1 running, 28 sleeping, 0 stopped, 0 zombie
    Cpu(s): 0.3% us, 1.0% sy, 0.0% ni, 98.7% id, 0.0% wa, 0.0% hi, 0.0% si
    Mem: 191272k total, 173656k used, 17616k free, 22052k buffers
    Swap: 192772k total, 0k used, 192772k free, 123988k cached

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    1379 root 16 0 7976 2456 1980 S 0.7 1.3 0:11.03 sshd
    14704 root 16 0 2128 980 796 R 0.7 0.5 0:02.72 top
    1 root 16 0 1992 632 544 S 0.0 0.3 0:00.90 init
    2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
    3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0

    统计信息区前五行是系统整体的统计信息。第一行是任务队列信息,同 uptime 命令的执行结果。其内容如下:
    01:06:48    当前时间
    up 1:22    系统运行时间,格式为时:分
    1 user    当前登录用户数
    load average: 0.06, 0.60, 0.48    系统负载,即任务队列的平均长度。
       三个数值分别为 1分钟、5分钟、15分钟前到现在的平均值。

    第二、三行为进程和CPU的信息。当有多个CPU时,这些内容可能会超过两行。内容如下:
    Tasks: 29 total    进程总数
    1 running    正在运行的进程数
    28 sleeping    睡眠的进程数
    0 stopped    停止的进程数
    0 zombie    僵尸进程数
    Cpu(s): 0.3% us    用户空间占用CPU百分比
    1.0% sy    内核空间占用CPU百分比
    0.0% ni    用户进程空间内改变过优先级的进程占用CPU百分比
    98.7% id    空闲CPU百分比
    0.0% wa    等待输入输出的CPU时间百分比
    0.0% hi    
    0.0% si    

    最后两行为内存信息。内容如下:
    Mem: 191272k total    物理内存总量
    173656k used    使用的物理内存总量
    17616k free    空闲内存总量
    22052k buffers    用作内核缓存的内存量
    Swap: 192772k total    交换区总量
    0k used    使用的交换区总量
    192772k free    空闲交换区总量
    123988k cached    缓冲的交换区总量。
                内存中的内容被换出到交换区,而后又被换入到内存,但使用过的交换区尚未被覆盖,
                该数值即为这些内容已存在于内存中的交换区的大小。
                相应的内存再次被换出时可不必再对交换区写入。

    进程信息区统计信息区域的下方显示了各个进程的详细信息。首先来认识一下各列的含义。
    列名    含义
    PID    进程id
    PPID    父进程id
    RUSER    Real user name
    UID    进程所有者的用户id
    USER    进程所有者的用户名
    GROUP    进程所有者的组名
    TTY    启动进程的终端名。不是从终端启动的进程则显示为 ?
    PR    优先级
    NI    nice值。负值表示高优先级,正值表示低优先级
    P    最后使用的CPU,仅在多CPU环境下有意义
    %CPU    上次更新到现在的CPU时间占用百分比
    TIME    进程使用的CPU时间总计,单位秒
    TIME+    进程使用的CPU时间总计,单位1/100秒
    %MEM    进程使用的物理内存百分比
    VIRT    进程使用的虚拟内存总量,单位kb。VIRT=SWAP+RES
    SWAP    进程使用的虚拟内存中,被换出的大小,单位kb。
    RES    进程使用的、未被换出的物理内存大小,单位kb。RES=CODE+DATA
    CODE    可执行代码占用的物理内存大小,单位kb
    DATA    可执行代码以外的部分(数据段+栈)占用的物理内存大小,单位kb
    SHR    共享内存大小,单位kb
    nFLT    页面错误次数
    nDRT    最后一次写入到现在,被修改过的页面数。
    S    进程状态。
                D=不可中断的睡眠状态
                R=运行
                S=睡眠
                T=跟踪/停止
                Z=僵尸进程
    COMMAND    命令名/命令行
    WCHAN    若该进程在睡眠,则显示睡眠中的系统函数名
    Flags    任务标志,参考 sched.h
    三、调试
    转载至linux load average 解析
    在查看了top命令所显示的状态后,需要依据其来做优化,但top命令显示的只是表象,所以我们可以通过iostat或者vmstat命令进一步的观察。
    3.1:查看系统负载vmstat
    vmstat
        procs -------memory-------- ----swap-- -----io---- --system-- ----cpu----
        r b swpd free buff cache si so bi bo in cs us sy id wa
        0 0 100152 2436 97200 289740 0 1 34 45 99 33 0 0 99 0
    procs
    r 列表示运行和等待cpu时间片的进程数,如果长期大于1,说明cpu不足,需要增加cpu。
    b 列表示在等待资源的进程数,比如正在等待I/O、或者内存交换等。
    cpu 表示cpu的使用状态
    us 列显示了用户方式下所花费 CPU 时间的百分比。us的值比较高时,说明用户进程消耗的cpu时间多,但是如果长期大于50%,需要考虑优化用户的程序。
    sy 列显示了内核进程所花费的cpu时间的百分比。这里us + sy的参考值为80%,如果us+sy 大于 80%说明可能存在CPU不足。
    wa 列显示了IO等待所占用的CPU时间的百分比。这里wa的参考值为30%,如果wa超过30%,说明IO等待严重,这可能是磁盘大量随机访问造成的,也可能磁盘或者磁盘访问控制器的带宽瓶颈造成的(主要是块操作)。
    id 列显示了cpu处在空闲状态的时间百分比
    system 显示采集间隔内发生的中断数
    in 列表示在某一时间间隔中观测到的每秒设备中断数。
    cs列表示每秒产生的上下文切换次数,如当 cs 比磁盘 I/O 和网络信息包速率高得多,都应进行进一步调查。
    memory
    swpd 切换到内存交换区的内存数量(k表示)。如果swpd的值不为0,或者比较大,比如超过了100m,只要si、so的值长期为0,系统性能还是正常
    free 当前的空闲页面列表中内存数量(k表示)
    buff 作为buffer cache的内存数量,一般对块设备的读写才需要缓冲。
    cache: 作为page cache的内存数量,一般作为文件系统的cache,如果cache较大,说明用到cache的文件较多,如果此时IO中bi比较小,说明文件系统效率比较好。
    swap
    si 由内存进入内存交换区数量。
    so由内存交换区进入内存数量。
    IO
    bi 从块设备读入数据的总量(读磁盘)(每秒kb)。
    bo 块设备写入数据的总量(写磁盘)(每秒kb)
    这里我们设置的bi+bo参考值为1000,如果超过1000,而且wa值较大应该考虑均衡磁盘负载,可以结合iostat输出来分析。
    3.2:查看磁盘负载iostat
    每隔2秒统计一次磁盘IO信息,直到按Ctrl+C终止程序,-d 选项表示统计磁盘信息, -k 表示以每秒KB的形式显示,-t 要求打印出时间信息,2 表示每隔 2 秒输出一次。第一次输出的磁盘IO负载状况提供了关于自从系统启动以来的统计信息。随后的每一次输出则是每个间隔之间的平均IO负载状况。
    # iostat -x 1 10
    Linux 2.6.18-92.el5xen 02/03/2009
    avg-cpu: %user %nice %system %iowait %steal %idle
    1.10 0.00 4.82 39.54 0.07 54.46
    Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
    sda 0.00 3.50 0.40 2.50 5.60 48.00 18.48 0.00 0.97 0.97 0.28
    sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
    sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
    sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
    sde 0.00 0.10 0.30 0.20 2.40 2.40 9.60 0.00 1.60 1.60 0.08
    sdf 17.40 0.50 102.00 0.20 12095.20 5.60 118.40 0.70 6.81 2.09 21.36
    sdg 232.40 1.90 379.70 0.50 76451.20 19.20 201.13 4.94 13.78 2.45 93.16
    rrqm/s: 每秒进行 merge 的读操作数目。即 delta(rmerge)/s
    wrqm/s: 每秒进行 merge 的写操作数目。即 delta(wmerge)/s
    r/s: 每秒完成的读 I/O 设备次数。即 delta(rio)/s
    w/s: 每秒完成的写 I/O 设备次数。即 delta(wio)/s
    rsec/s: 每秒读扇区数。即 delta(rsect)/s
    wsec/s: 每秒写扇区数。即 delta(wsect)/s
    rkB/s: 每秒读K字节数。是 rsect/s 的一半,因为每扇区大小为512字节。(需要计算)
    wkB/s: 每秒写K字节数。是 wsect/s 的一半。(需要计算)
    avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
    avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
    await: 平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
    svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
    %util: 一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)
    如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘
    可能存在瓶颈。
    idle小于70% IO压力就较大了,一般读取速度有较多的wait.
    同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)
    另外还可以参考
    一般:
    svctm < await (因为同时等待的请求的等待时间被重复计算了),
    svctm的大小一般和磁盘性能有关:CPU/内存的负荷也会对其有影响,请求过多也会间接导致 svctm 的增加。
    await: await的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。
    如果 svctm 比较接近 await,说明I/O 几乎没有等待时间;
    如果 await 远大于 svctm,说明 I/O队列太长,应用得到的响应时间变慢,
    如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘,调整内核 elevator算法,优化应用,或者升级 CPU。
    队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标,但由于 avgqu-sz 是按照单位时间的平均值,所以不能反映瞬间的 I/O 洪水。
    别人一个不错的例子.(I/O 系统 vs. 超市排队)
    举一个例子,我们在超市排队 checkout 时,怎么决定该去哪个交款台呢? 首当是看排的队人数,5个人总比20人要快吧?除了数人头,我们也常常看看前面人购买的东西多少,如果前面有个采购了一星期食品的大妈,那么可以考虑换个队排了。还有就是收银员的速度了,如果碰上了连钱都点不清楚的新手,那就有的等了。另外,时机也很重要,可能 5分钟前还人满为患的收款台,现在已是人去楼空,这时候交款可是很爽啊,当然,前提是那过去的 5 分钟里所做的事情比排队要有意义(不过我还没发现什么事情比排队还无聊的)。
    I/O 系统也和超市排队有很多类似之处:
    r/s+w/s 类似于交款人的总数
    平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数
    平均服务时间(svctm)类似于收银员的收款速度
    平均等待时间(await)类似于平均每人的等待时间
    平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少
    I/O 操作率 (%util)类似于收款台前有人排队的时间比例。
    我们可以根据这些数据分析出 I/O 请求的模式,以及 I/O 的速度和响应时间。
    下面是别人写的这个参数输出的分析
    # iostat -x 1
    avg-cpu: %user %nice %sys %idle
    16.24 0.00 4.31 79.44
    Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
    /dev/cciss/c0d0
    0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
    /dev/cciss/c0d0p1
    0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
    /dev/cciss/c0d0p2
    0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
    上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作: 总IO(io)/s = r/s(读) +w/s(写) = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1)。
    平均每次设备 I/O 操作只需要 5ms 就可以完成,但每个 I/O 请求却需要等上 78ms,为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个),假设这些请求是同时发出的,那么平均等待时间可以这样计算:
    平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + ... + 请求总数-1) / 请求总数
    应用到上面的例子: 平均等待时间 = 5ms * (1+2+...+28)/29 = 70ms,和 iostat 给出的78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。
    每秒发出的 I/O 请求很多 (约 29 个),平均队列却不长 (只有 2 个 左右),这表明这 29 个请求的到来并不均匀,大部分时间 I/O 是空闲的。
    一秒中有 14.29% 的时间 I/O 队列中是有请求的,也就是说,85.71% 的时间里 I/O 系统无事可做,所有 29 个 I/O 请求都在142毫秒之内处理掉了。
    delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s=78.21 * delta(io)/s = 78.21*28.57 =2232.8,表明每秒内的I/O请求总共需要等待2232.8ms。所以平均队列长度应为 2232.8ms/1000ms = 2.23,而iostat 给出的平均队列长度 (avgqu-sz) 却为 22.35,为什么?! 因为 iostat 中有 bug,avgqu-sz值应为 2.23,而不是 22.35。

    展开全文
  • System.loadSystem.loadLibrary详解

    千次阅读 2015-04-09 15:35:04
    System.loadSystem.loadLibrary详解 1.它们都可以用来装载库文件,不论是JNI库文件还是非JNI库文件。在任何本地方法被调用之前必须先用这个两个方法之一把相应的JNI库文件装载。 2.System.load 参数为库文件...
  • System.loadSystem.loadLibrary 的区别

    千次阅读 2019-07-06 15:20:21
    相同点 它们都可以用来装载库文件,不论是JNI库文件还是非JNI库文件...System.load 参数必须为库文件的绝对路径,可以是任意路径,例如:System.load("C:\\Documents and Settings\\TestJNI.dll"); //Windows Syst...
  • System.loadSystem.loadLibrary

    千次阅读 2011-11-11 20:54:58
    1.它们都可以用来装载库文件,不论是JNI库...2.System.load 参数为库文件的绝对路径,可以是任意路径。 例如你可以这样载入一个windows平台下JNI库文件: System.load("C:\\Documents and Settings\\TestJNI.dll");。
  • system load 系统类load()方法 (System class load() method) load() method is available in java.lang package. load()方法在java.lang包中可用。 load() method is used to load the java file with the given ...
  • Linux load average负载量分析与解决思路

    万次阅读 多人点赞 2014-02-19 15:35:42
    top命令中load average显示的是最近1分钟、5分钟和15分钟的系统平均负载。系统平均负载表示  系统平均负载被定义为在特定时间间隔内运行队列中(在CPU上运行或者等待运行多少进程)的平均进程树。如果一个进程满足...
  • Linux-Load Average

    2012-10-12 12:51:37
    Definition: ... the system load is a measure of the amount of computational work that a computer system performs. The load average represents the average system load over a perio
  • 本文来源于...为了搞清楚Load average的概念,作者甚至追溯到了24年前的Linux提交记录。最后彻底把load average理了个底朝天。 快,关注Linuxer公众号,一起涨姿势~ Linux Load Averages: Solvi
  • linux--load解释

    千次阅读 2016-08-29 10:15:26
    linux系统中的Load对当前CPU工作量的度量 (WikiPedia: the system load is a measure of the amount of work that a computer system is doing)。也有简单的说是进程队列的长度。 Load Average 就是一段时间 ...
  • Linux系统负载LoadAverage详解

    千次阅读 2016-04-27 00:02:36
    为此笔者总结了一下如何通过loadaverage返回的数据来判断系统运行情况。 什么是Load?什么是Load Average? Load用最通俗的语言说就是当前cpu需要干的工作量的多少。简单的说是进程队列的长度。
  • MATLAB (2013b) “doc” cannot load libxul.so from Java on Linux systemHelp browserThe help browser uses valuable slots in the dynamic thread vector and causes competition with core functionality ...
  • linux 负载(load average)分析

    千次阅读 2017-07-28 10:36:18
     Linux的负载,主要是由于CPU使用、内存使用、IO消耗三部分构成。任意一项使用过多,都将导致服务器负载的急剧攀升 服务器负载故障排查 1:在top命令下,按1,则可以展示出服务器有多少CPU,及每个CPU的使用...
  • 原贴:http://www.dbanotes.net/arch/unix_linux_load.htmlUnix/LinuxLoad 初级解释 作者: Fenng | 可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明网址: ...load.html
  • System.load()与System.loadLibrary()方法均能够加载Windows环境、Linux环境下的动态库文件,而且不区分是封装好的JNI库文件或者非JNI库文件。 当带有native关键字的本地方法在被调用时,都会通过这两种方式之一将...
  • Linux 性能监控 —— Load Average

    千次阅读 2016-01-20 20:43:09
    网站加载不出来? 一朵小菊花不停地转动,可能 Load Average 可以告诉你答案...
  • 一、什么是load average?...linux系统中的Load对当前CPU工作量的度量 (WikiPedia: the system load is a measure of the amount of work that a computer system is doing)。也有简单的说是进
  • CPU load高但CPU usage低问题排查

    千次阅读 2020-10-19 18:44:13
    查看内存使用情况:mem.memused 接近100%,查看磁盘情况:swap.used周期性(30分钟左右)的较, disk.io.util 低,但是 disk.io.avgqu-sz(平均请求队列的长度)周期性(30分钟左右)的较,且和 cpu load高 同频。...
  • 最近研究linux时接触到了一个新的概念,叫做CPU的平均负载(load average)。之前都只听说过CPU的使用情况,很少听说过负载情况。于是对这个概念进行了一下研究学习,总结如下,以便日后查阅。
  • System.load()与System.loadLibrary() ,System.loadLibrary() Android System.loadLibrary及JNI_OnLoad简介 --http://blog.csdn.net/myarrow/article/details/9718677 System.loadSystem.loadLibrary详解-- ...
  • linux系统中的Load对当前CPU工作量的度量 (WikiPedia: the system load is a measure of the amount of work that a computer system is doing)。也有简单的说是进程队列的长度。 Load Average 就是一段时间 (1 ...
  • Java调用第三方dll文件的使用方法 public class OtherAdapter { static { //System.loadLibrary("Connector");//载入需要调用的dll Connector.... System.load("d://Connector.dll");//载入dll Connector.dll ...
  • Linux 监控指标分析- load average

    千次阅读 2014-06-26 23:53:40
    ...linux系统中的Load对当前CPU工作量的度量 (WikiPedia: the system load is a measure of the amount of work that a computer system is doing)。也有简单的说是进程队列的长度。 Load Ave

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 111,815
精华内容 44,726
关键字:

linuxload高system

linux 订阅