精华内容
下载资源
问答
  • 和 CPU 使用率并没有直接的关系一般的进程需要消耗 CPU、内存、磁盘I/O、网络I/O等资源,在这种情况下,平均负载就不是单独指的CPU使用情况。即内存、磁盘、网络等因素也可以影响系统的平均负载值。不过影响最大的是...

    load average 的含义

    平均负载是指单位时间内,系统处于可运行状态和不可中断状态的平均进程数。和 CPU 使用率并没有直接的关系

    一般的进程需要消耗 CPU、内存、磁盘I/O、网络I/O等资源,在这种情况下,平均负载就不是单独指的CPU使用情况。即内存、磁盘、网络等因素也可以影响系统的平均负载值。不过影响最大的是 CPU 使用率、CPU 等待和磁盘I/O。

    一个机器的负载情况通常是通过 CPU 核数来判断的。当平均负载比 CPU 核数还大的时候,系统已经出现了过载。

    如在单核处理器中,平均负载值为 1 或者小于 1 的时候,系统处理进程会非常轻松,即负载很低。当达到 3 的时候,就会显得很忙,达到 5 或者 8 的时候就不能很好的处理进程了(其中 5 和 8 目前还是个争议的阈值,为了保守起见,建议选择低的)。

    查看load average 数据

    下面几个命令都可以看到 load average

    1

    2

    3# top

    # uptime

    # w

    截图如下:

    top 命令:

    uptime 命令:

    w 命令:

    这里的 load average 的三个值分别指系统在最后 1/5/15 分钟 的平均负载值。

    根据经验:我们应该把重点放在5/15分钟的平均负载,因为 1 分钟的平均负载太频繁,一瞬间的高并发就会导致该值的大幅度改变。

    平均负载与 CPU 使用率

    在日常使用中,我们经常容易把平均负载和 CPU 使用率混淆,这里我们做下区分。

    可能我们会有疑惑,既然平均负载代表的是活跃进程数,那么平均负载高了,不就意味着 CPU 使用率高了吗?

    这里我们还得回到平均负载的含义上来,平均负载是指单位时间内,处于可运行状态和不可中断状态的进程数。所以,他不仅包扩了正在使用CPU的进程,还包括等待 CPU和等待磁盘I/O的进程。

    而 CPU 使用率,是单位时间内 CPU 繁忙情况的统计,和平均负载并不一定完全对应。比如:

    CPU 密集型进程,使用大量 CPU 会导致平均负载升高,此时这两者是一致的。

    I/O 密集型进程, 等待 I/O 也会导致平均负载升高,但是 CPU 使用率不一定很高。

    大量等待CPU的进程调用也会导致平均负载升高,此时的 CPU 使用率也会比较高。

    平均负载案例分析

    机器是一个 16 核 CPU 的。

    这里会用到 2 个工具,stress 和 sysstat。

    stress 是一个 Linux 系统压力测试工具,这里我们用作异常进程模拟平均负载升高的场景。

    sysstat 是一个 Linux 性能工具,用来监控和分析系统的性能,以下案例中会用到这个包的 2 个命令 mpstat 和 pidstat。

    mpstat 是一个常用的多核 CPU 性能分析工具,用来实时查看每个 CPU 的性能指标,以及所有 CPU 的平均指标。

    pidstat 是一个常用的进程性能分析工具,用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

    场景1:CPU密集型进程

    我们打开终端一运行 stree 命令,模拟一个 CPU 使用率 100% 的场景

    1

    2[root@localhost ~]# stress --cpu 1 --timeout 600

    stress: info: [5399] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd

    我们打开终端二,查看 CPU 负载的上升状态

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10[root@localhost ~]# uptime

    01:50:42 up 1 day, 1:42, 3 users, load average: 0.68, 0.22, 0.11

    [root@localhost ~]# uptime

    01:50:45 up 1 day, 1:42, 3 users, load average: 0.71, 0.23, 0.12

    [root@localhost ~]# uptime

    01:51:10 up 1 day, 1:43, 3 users, load average: 0.81, 0.29, 0.14

    [root@localhost ~]# uptime

    01:54:58 up 1 day, 1:47, 4 users, load average: 1.03, 0.68, 0.33

    # 一段时间后,我们发现1分钟的平均 load 值超过了1,为啥? 设备上还有些其他进程运行啊。

    打开终端三,查看 CPU 使用状态

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    16

    17

    18

    19

    20

    21

    22

    23[root@localhost ~]# mpstat -P ALL 5

    Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain) 11/24/2018 _x86_64_ (16 CPU)

    01:53:08 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle

    01:53:13 AM all 6.24 0.00 0.01 0.00 0.00 0.00 0.01 0.00 0.00 93.73

    01:53:13 AM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.20 0.00 0.00 99.80

    01:53:13 AM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

    01:53:13 AM 2 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.80

    01:53:13 AM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

    01:53:13 AM 4 0.00 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 99.80

    01:53:13 AM 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

    01:53:13 AM 6 0.00 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 99.80

    01:53:13 AM 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

    01:53:13 AM 8 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.80

    01:53:13 AM 9 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

    01:53:13 AM 10 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

    01:53:13 AM 11 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

    01:53:13 AM 12 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

    01:53:13 AM 13 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

    01:53:13 AM 14 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

    01:53:13 AM 15 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

    # 这里我们可以看到,在CPU15上 CPU的使用率一直处于100%状态,使用这个工具可以持续看到状态的变化。

    从终端二中可以看到,1 分钟的平均负载慢慢会增加到 1;而从终端三中可以看到,正好有一个 CPU 的使用率为 100%,但他的 iowait 为 0。这说明,平均负载的升高正是由于 CPU 使用率为 100% 导致的。

    那么,到底是哪个进程导致了 CPU 使用率为 100% 呢? 你可以使用 pidstat 来查询:

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12[root@localhost ~]# pidstat -u 5 1

    Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain) 11/24/2018 _x86_64_ (16 CPU)

    02:00:20 AM UID PID %usr %system %guest %CPU CPU Command

    02:00:25 AM 0 8451 100.00 0.00 0.00 100.00 2 stress

    02:00:25 AM 0 8456 0.00 0.20 0.00 0.20 3 pidstat

    02:00:25 AM 0 8457 0.20 0.20 0.00 0.40 15 client

    Average: UID PID %usr %system %guest %CPU CPU Command

    Average: 0 8451 100.00 0.00 0.00 100.00 - stress

    Average: 0 8456 0.00 0.20 0.00 0.20 - pidstat

    Average: 0 8457 0.20 0.20 0.00 0.40 - client

    从这里,可以明显看到,stress 进程的 CPU 使用率为 100%。

    场景二:I/O 密集型进程

    首先还是运行 stress 命令,但这次模拟 I/O 压力,即不停的执行 sync。

    打开终端一,执行 stress

    1

    2[root@localhost ~]# stress -i 1 --timeout 3600

    stress: info: [8817] dispatching hogs: 0 cpu, 1 io, 0 vm, 0 hdd

    打开终端二

    1

    2

    3

    4

    5

    6[root@localhost ~]# uptime

    02:02:36 up 1 day, 1:54, 4 users, load average: 0.83, 0.85, 0.56

    [root@localhost ~]# uptime

    02:05:27 up 1 day, 1:57, 4 users, load average: 0.99, 0.92, 0.63

    # 这里,也会看到,load会不断的升高

    打开终端三

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    16

    17

    18

    19

    20

    21

    22

    23

    24[root@localhost ~]# mpstat -P ALL 5

    Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain) 11/24/2018 _x86_64_ (16 CPU)

    Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle

    Average: all 0.05 0.00 5.93 0.34 0.00 0.00 0.05 0.00 0.00 93.63

    Average: 0 0.16 0.00 0.48 0.00 0.00 0.00 0.14 0.00 0.00 99.22

    Average: 1 0.03 0.00 0.09 0.01 0.00 0.00 0.03 0.00 0.00 99.84

    Average: 2 0.03 0.00 0.09 0.00 0.00 0.00 0.01 0.00 0.00 99.88

    Average: 3 0.09 0.00 0.23 0.00 0.00 0.00 0.03 0.00 0.00 99.65

    Average: 4 0.13 0.00 0.53 0.00 0.00 0.00 0.05 0.00 0.00 99.29

    Average: 5 0.02 0.00 0.05 0.00 0.00 0.00 0.05 0.00 0.00 99.88

    Average: 6 0.02 0.00 0.35 0.00 0.00 0.00 0.08 0.00 0.00 99.56

    Average: 7 0.02 0.00 0.04 0.00 0.00 0.00 0.03 0.00 0.00 99.90

    Average: 8 0.02 0.00 0.14 0.00 0.00 0.00 0.04 0.00 0.00 99.80

    Average: 9 0.10 0.00 0.28 0.00 0.00 0.00 0.03 0.00 0.00 99.59

    Average: 10 0.09 0.00 0.34 0.00 0.00 0.00 0.05 0.00 0.00 99.52

    Average: 11 0.01 0.00 0.06 0.00 0.00 0.00 0.03 0.00 0.00 99.90

    Average: 12 0.03 0.00 33.73 1.96 0.00 0.00 0.05 0.00 0.00 64.23

    Average: 13 0.02 0.00 0.04 0.00 0.00 0.00 0.02 0.00 0.00 99.92

    Average: 14 0.03 0.00 2.43 0.12 0.00 0.00 0.04 0.00 0.00 97.37

    Average: 15 0.04 0.00 56.38 3.30 0.00 0.00 0.17 0.00 0.00 40.12

    # 这里看到,CPU 的 use 使用不是很高,反而 sys 使用的比较高,分布在了 2 个 CPU 上,约等于 100%

    # 同时可以看到 iowait 的值也升高了一些,由于我的设备全是 ssd 磁盘,所以这个 io 的性能可能会稍微好一些。

    从以上操作中,我们看到 1 分钟的平均负载会慢慢的增加,其中一个 CPU 的系统 CPU 使用率提升到了 56 ,同时 iowait 也提升到了 3,这说明平均负载的升高是由于系统资源使用和 iowait 导致。

    这里更新 sysstat 包的版本

    1

    2[root@localhost ~]# wget http://pagesperso-orange.fr/sebastien.godard/sysstat-12.1.1-1.x86_64.rpm

    [root@localhost ~]# rpm -Uvh sysstat-12.1.1-1.x86_64.rpm

    那么到底是哪个进程,导致系统 CPU 使用率特别高,及 CPU 的等待 wait 情况

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13[root@localhost ~]# pidstat -u 5 1

    Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain) 11/24/2018 _x86_64_ (16 CPU)

    02:34:53 AM UID PID %usr %system %guest %wait %CPU CPU Command

    02:34:58 AM 0 730 0.00 0.20 0.00 0.00 0.20 12 xfsaild/vda6

    02:34:58 AM 0 1471 0.00 0.20 0.00 0.00 0.20 10 kworker/10:2

    02:34:58 AM 0 3042 0.00 0.40 0.00 0.00 0.40 7 kworker/7:1H

    02:34:58 AM 0 11617 0.00 1.59 0.00 0.00 1.59 2 kworker/u32:1

    02:34:58 AM 0 15272 0.00 91.43 0.00 0.40 91.43 7 stress

    02:34:58 AM 0 15273 0.00 0.20 0.00 0.00 0.20 14 kworker/u32:0

    02:34:58 AM 0 15274 0.20 0.40 0.00 0.00 0.60 5 pidstat

    # %wait:表示等待运行时任务占用 CPU 百分比。

    通过以上的信息,可以很清晰的看到,是由于 stress 进程出现了大量的系统使用。

    场景三:大量进程的场景

    当系统中运行进程超出CPU运行能力时,就会出现等待CPU的进程。

    我们打开终端一:使用 stress 模拟 24 个进程

    1

    2[root@localhost ~]# stress -c 24 --timeout 3600

    stress: info: [11726] dispatching hogs: 24 cpu, 0 io, 0 vm, 0 hdd

    打开终端二:看下当前的负载值

    1

    2

    3

    4

    5

    6[root@localhost ~]# uptime

    02:20:36 up 1 day, 2:12, 4 users, load average: 17.22, 5.98, 2.61

    [root@localhost ~]# uptime

    02:20:52 up 1 day, 2:13, 4 users, load average: 18.72, 6.86, 2.95

    [root@localhost ~]# uptime

    02:24:03 up 1 day, 2:16, 4 users, load average: 23.77, 14.94, 6.85

    打开终端三:看下进程的资源使用信息

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    16

    17

    18

    19

    20

    21

    22

    23

    24

    25

    26

    27

    28

    29

    30

    31[root@localhost ~]# pidstat -u 5 1

    Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain) 11/24/2018 _x86_64_ (16 CPU)

    02:28:14 AM UID PID %usr %system %guest %wait %CPU CPU Command

    02:28:19 AM 0 43 0.00 0.20 0.00 0.00 0.20 7 ksoftirqd/7

    02:28:19 AM 0 2292 0.20 0.00 0.00 0.00 0.20 11 dstat

    02:28:19 AM 0 11727 48.81 0.00 0.00 44.05 48.81 5 stress

    02:28:19 AM 0 11728 44.64 0.00 0.00 0.00 44.64 12 stress

    02:28:19 AM 0 11729 41.27 0.00 0.00 49.60 41.27 11 stress

    02:28:19 AM 0 11730 46.03 0.00 0.00 41.27 46.03 2 stress

    02:28:19 AM 0 11731 59.92 0.00 0.00 30.16 59.92 15 stress

    02:28:19 AM 0 11732 47.62 0.00 0.00 25.60 47.62 13 stress

    02:28:19 AM 0 11733 65.67 0.00 0.00 22.02 65.67 2 stress

    02:28:19 AM 0 11734 41.67 0.00 0.00 50.40 41.67 10 stress

    02:28:19 AM 0 11735 54.17 0.00 0.00 32.34 54.17 15 stress

    02:28:19 AM 0 11736 42.06 0.00 0.00 50.20 42.06 6 stress

    02:28:19 AM 0 11737 35.91 0.00 0.00 29.96 35.91 3 stress

    02:28:19 AM 0 11738 50.20 0.00 0.00 5.16 50.20 10 stress

    02:28:19 AM 0 11739 42.06 0.00 0.00 49.60 42.06 6 stress

    02:28:19 AM 0 11740 58.73 0.00 0.00 34.92 58.73 4 stress

    02:28:19 AM 0 11741 46.63 0.00 0.00 13.49 46.63 1 stress

    02:28:19 AM 0 11742 43.45 0.00 0.00 50.79 43.45 14 stress

    02:28:19 AM 0 11743 44.05 0.00 0.00 45.24 44.05 7 stress

    02:28:19 AM 0 11744 56.55 0.00 0.00 12.70 56.55 0 stress

    02:28:19 AM 0 11745 46.23 0.00 0.00 49.80 46.23 5 stress

    02:28:19 AM 0 11746 49.40 0.00 0.00 41.27 49.40 11 stress

    02:28:19 AM 0 11747 43.65 0.00 0.00 49.40 43.65 14 stress

    02:28:19 AM 0 11748 59.33 0.00 0.00 0.99 59.33 8 stress

    02:28:19 AM 0 11749 46.43 0.00 0.00 45.24 46.43 4 stress

    02:28:19 AM 0 11750 51.19 0.00 0.00 24.60 51.19 9 stress

    02:28:19 AM 0 14276 0.00 0.40 0.00 0.20 0.40 10 pidstat

    我们发现,运行的 24 个 stress 进程,出现了资源争抢的问题,既然出现了资源争抢,就会出现等待时间 wait。

    注意事项

    1、iowait 不等于 cpu wait。

    2、iowait 多少算高。

    1

    2

    3一般 iowait 达 30% 就算高了,需要关注。

    使用:iostat -x 1 10

    其中如果 %util 到 70%,那么磁盘IO 就很频繁了,需要重点关注。

    参考文章

    展开全文
  • 但是它并不像我们习惯中Windows、Mac操作系统提供百分比显示CPU、内存占用率,而是以几个用空格隔开的浮点数来表示系统平均负载,那么它们到底是什么意思呢?又如何衡量系统负载及系统...

    越来越多人开始接触Linux操作系统,从VPS到无线路由的刷机系统(如OpenWRT、Tomato),同时也必不可少地会在各式各样的探针和系统监测界面上看到"系统平均负载"或者"Load Average"这样的字眼,但是它并不像我们习惯中Windows、Mac操作系统提供百分比显示CPU、内存占用率,而是以几个用空格隔开的浮点数来表示系统平均负载,那么它们到底是什么意思呢?又如何衡量系统负载及系统的稳定性呢?

    系统平均负载-基本解释

    在Linux shell下,有很多命令可以看到Load Average,例如:

    root@Slyar.com:~# uptime

    12:49:10 up 182 days, 16:54, 2 users, load average: 0.08, 0.04, 0.01

    root@Slyar.com:~# w

    12:49:18 up 182 days, 16:54, 2 users, load average: 0.11, 0.07, 0.01

    root@Slyar.com:~# top

    top - 12:50:28 up 182 days, 16:55, 2 users, load average: 0.02, 0.05, 0.00

    先大致给一下这3个数字的含义:分别表示系统在过去1分钟、5分钟、15分钟内运行进程队列中的平均进程数量。

    运行队列嘛,没有等待IO,没有WAIT,没有KILL的进程通通都进这个队列。

    另外还有一个最直接的显示系统平均负载的命令

    root@Slyar.com:~# cat /proc/loadavg

    0.10 0.06 0.01 1/72 29632

    除了前3个数字表示平均进程数量外,后面的1个分数,分母表示系统进程总数,分子表示正在运行的进程数;最后一个数字表示最近运行的进程ID.

    系统平均负载-进阶解释

    只是上面那一句话的解释,基本等于没解释。写这篇文章的缘由就是因为看到了一篇老外写的关于Load Average的文章,觉得解释的很好,所以才打算摘取一部分用自己的话翻译一下。

    @scoutapp Thanks for your article

    为了更好地理解系统负载,我们用交通流量来做类比。

    1、单核CPU - 单车道 - 数字在0.00-1.00之间正常

    路况管理员会告知司机,如果前面比较拥堵,那司机就要等待,如果前面一路畅通,那么司机就可以驾车直接开过。

    具体来说:

    0.00-1.00 之间的数字表示此时路况非常良好,没有拥堵,车辆可以毫无阻碍地通过。

    1.00 表示道路还算正常,但有可能会恶化并造成拥堵。此时系统已经没有多余的资源了,管理员需要进行优化。

    1.00-*** 表示路况不太好了,如果到达2.00表示有桥上车辆一倍数目的车辆正在等待。这种情况你必须进行检查了。

    2、多核CPU - 多车道 - 数字/CPU核数 在0.00-1.00之间正常

    多核CPU的话,满负荷状态的数字为 "1.00 * CPU核数",即双核CPU为2.00,四核CPU为4.00。

    3、安全的系统平均负载

    作者认为单核负载在0.7以下是安全的,超过0.7就需要进行优化了。

    4、应该看哪一个数字,1分钟,5分钟还是15分钟?

    作者认为看5分钟和15分钟的比较好,即后面2个数字。

    5、怎样知道我的CPU是几核呢?

    使用以下命令可以直接获得CPU核心数目

    grep 'model name' /proc/cpuinfo | wc -

    转:http://www.slyar.com/blog/linux-load-average-three-numbers.html

    展开全文
  • top命令是看当前进程的cpu和内存等的占用情况参数解析top - 20:54:37 up 228 days, 11:03, 3 users, load average: 0.54, 0.33, 0.32Tasks: 266 total, 1 running, 265 sleeping, 0 stopped, 0 zombie%Cpu(s): 0.3 ...

    top命令是看当前进程的cpu和内存等的占用情况

    参数解析

    top - 20:54:37 up 228 days, 11:03, 3 users, load average: 0.54, 0.33, 0.32

    Tasks: 266 total, 1 running, 265 sleeping, 0 stopped, 0 zombie

    %Cpu(s): 0.3 us, 0.3 sy, 0.0 ni, 99.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

    KiB Mem : 65806688 total, 3267880 free, 51877252 used, 10661556 buff/cache

    KiB Swap: 0 total, 0 free, 0 used. 12528752 avail Mem

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

    4048 hadoop 20 0 24.9g 1.5g 11372 S 2.7 2.4 1168:24 java

    10359 root 20 0 122712 19332 2612 S 2.3 0.0 12:48.32 flux_app

    6006 hadoop 20 0 14.7g 1.8g 10964 S 2.0 2.8 5915:47 presto-server

    5735 root 20 0 2767844 621184 9808 S 0.7 0.9 3197:27 360entclient

    对上面第三行的解释:

    us(user cpu time):用户态使用的cpu时间比。该值较高时,说明用户进程消耗的 CPU 时间比较多,比如,如果该值长期超过 50%,则需要对程序算法或代码等进行优化。

    sy(system cpu time):系统态使用的cpu时间比。

    ni(user nice cpu time):用做nice加权的进程分配的用户态cpu时间比

    id(idle cpu time):空闲的cpu时间比。如果该值持续为0,同时sy是us的两倍,则通常说明系统则面临着 CPU 资源的短缺。

    wa(io wait cpu time):cpu等待磁盘写入完成时间。该值较高时,说明IO等待比较严重,这可能磁盘大量作随机访问造成的,也可能是磁盘性能出现了瓶颈。

    hi(hardware irq):硬中断消耗时间

    si(software irq):软中断消耗时间

    st(steal time):虚拟机偷取时间

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

    4048 hadoop 20 0 24.9g 1.5g 11372 S 2.7 2.4 1168:24 java

    10359 root 20 0 122712 19332 2612 S 2.3 0.0 12:48.32 flux_app

    6006 hadoop 20 0 14.7g 1.8g 10964 S 2.0 2.8 5915:47 presto-server

    5735 root 20 0 2767844 621184 9808 S 0.7 0.9 3197:27 360entclient

    以上图来说几个重要的参数情况

    PID 进程号

    USER 运行用户

    VIRT 进程使用的虚拟内存总量

    RES 物理内存用量

    SHR 共享内存用量

    %CPU 该进程自最近一次刷新以来所占用的CPU时间和总时间的百分比

    %CPU显示的是进程占用一个核的百分比,而不是整个cpu(12核)的百分比,有时候可能大于100,那是因为该进程启用了多线程占用了多个核心,所以有时候我们看该值得时候会超过100%,但不会超过总核数*100

    (%CPU>100的情况 这里显示的所有的cpu加起来的使用率,说明你的CPU是多核 你运行top后按大键盘1看看,可以显示每个cpu的使用率,top里显示的是把所有使用率加起来。 )

    %MEM 该进程占用的物理内存占总内存的百分比

    COMMAND 该进程的命令名称,如果一行显示不下,则会进行截取。内存中的进程会有一个完整的命令行

    load average 浅析

    上述top命令中的load average: 0.54, 0.33, 0.32 表示了load average的一分钟,五分钟,十五分钟的平均CPU负载

    所谓的CPU负载指的是一段时间内任务队列的长度,通俗的讲,就是一段时间内一共有多少任务在使用或等待使用CPU。(当前的"负载值除以cpu核数"就是cpu的利用率)

    当CPU完全空闲的时候,平均负荷为0(即load average的值为0);当CPU工作量饱和的时候,平均负荷为1。

    这里需要注意的是:

    load average这个输出值,这三个值的大小一般不能大于系统逻辑CPU的个数

    比如一台服务器有4个逻辑CPU,如果load average的三个值长期大于4时,说明CPU很繁忙,负载很高,可能会影响系统性能;

    但是偶尔大于4时,倒不用担心,一般不会影响系统性能。

    load average举例理解

    判断系统负荷是否过重,必须理解load average的真正含义。假设当前我的一台服务器只有一个CPU,所有的运算都必须由这个CPU来完成。

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

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

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

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

    4)系统负荷为1.7,意味着车辆太多了,大桥已经被占满了(100%),后面等着上桥的车辆为桥面车辆的70%。

    以此类推,系统负荷2.0,意味着等待上桥的车辆与桥面的车辆一样多;

    系统负荷3.0,意味着等待上桥的车辆是桥面车辆的2倍。

    总之,当系统负荷大于1,后面的车辆就必须等待了;系统负荷越大,过桥就必须等得越久。

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

    如果CPU每分钟最多处理100个进程,那么:

    系统负荷0.2,意味着CPU在这1分钟里只处理20个进程;

    系统负荷1.0,意味着CPU在这1分钟 里正好处理100个进程;

    系统负荷1.7,意味着除了CPU正在处理的100个进程以外,还有70个进程正排队等着CPU处理。

    上面,假设我的这台服务器只有1个CPU。如果它装了2个CPU,就意味着服务器的处理能力翻了一倍,能够同时处理的进程数量也翻了一倍。

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

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

    至于load average是多少才算理想,这个有争议,各有各的说法

    个人比较赞同CPU负载小于等于"内核数乘以0.5-0.7"算是一种理想状态。

    load average返回三个平均值应该参考哪个值

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

    如果15分钟内,平均系统负荷大于1.0(调整CPU核心数之后),表明问题持续存在,不是暂时现象。

    所以应该主要观察"15分钟系统负荷",将它作为服务器正常运行的指标。

    除去CPU性能上的差异,CPU负载是基于内核数来计算的。有一个说法是"有多少内核,即有多少负载"。

    展开全文
  • 注:系统的负载看是否正常取决cpu的核心数比如8颗cpu。负载1分钟的地方超过8就是过载了。下图中显示cpu数量为1所以负载值为1最好,保证比cpu数量值小就没问题 查看cup多少数量如下 10.2 vmstat命令 vmstat命令...

    10.1 使用w查看系统负载

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    w命令监控系统的负载状态 如下

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)
    注:系统的负载看是否正常取决cpu的核心数比如8颗cpu。负载1分钟的地方超过8就是过载了。
    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)
    下图中显示cpu数量为1所以负载值为1最好,保证比cpu数量值小就没问题

    查看cup多少数量如下

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    10.2 vmstat命令

    vmstat命令能够查看到cpu ,内存 ,虚拟磁盘 ,交换分区 , io磁盘 ,系统进程 ,等相关的东西如下图:

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    这个命令的用法vmstat 1 如下图

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    vmstat 1 5如下

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    10.3 top命令

    查看进程使用资源的情况,查看具体的进程。如下

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)
    退出top按q即可

    top -c

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    top -bn1

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    10.4 sar命令

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    sar

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    sar -n DEV 网卡流量

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    sar -n DEV -f /var/log/sa/sa11查看生成的历史网卡状态

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)
    注:这个目录下最多保留一个月

    sar -q 系统负载

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    sar -b 磁盘读写

    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    nload命令

    nload监控网卡流量这个命令默认是没有安装的安装命令如下
    yum install -y epel-release
    yum install -y nload
    28次课(使用w查看系统负载、vmstat命令、top命令、sar命令、nload命令)

    转载于:https://blog.51cto.com/8043410/2064441

    展开全文
  • 启动时间:程序从运行到可以正常处理业务需要花费多少时间 负载承受能力:当系统压力上升时,系统的执行速度、响应时间的上升曲线是否平缓 衡量程序性能的主要指标: 执行时间:程序从运行到结束所使用的时间 CPU...
  • Java性能调优概述

    2018-11-19 07:00:17
    [TOC] Java性能调优概述 性能优化有风险和弊端,性能调优必须有明确的目标,不要为了调优而调优!!!盲目调优,风险远大于收益!...启动时间:程序从运行到可以正常处理业务需要花费多少时间 负载承...
  • 当前时间、系统已经运行了多长时间、有多少登陆用户、系统在过去的1分钟、5分钟和15分钟内的平均负载。平均负载的最佳值是1,这意味着每个进程都可以立即执行不会错过CPU周期。单核CPU,1-2是正常的,多核CPU,核心...
  • 执行速度:程序的反映是否迅速,响应时间是否足够短内存分配:内存分配是否合理,是否过多地消耗内存或者存在内存泄漏启动时间:程序从运行到可以正常处理业务需要花费多少时间负载承受能力:当系统压力上升时,系统...
  • 3、CPU的利用率——实际使用时间除以本身工作时间 CPU的平均负载——有多少任务需要执行除以可以执行的任务 4、平均负载系统显示3个时间(1分钟、5分钟、15分钟),更加精确的检测系统负载状态 ...
  • nf_conntrack

    2018-04-11 13:30:31
    (服务器用的阿里云主机,CentOS 7.3,似乎不管内存多少阿里云都把 conntrack_max 设成 65536) 症状CentOS服务器,负载正常,但请求大量超时,服务器/应用访问日志看不到相关请求记录。 在dmesg或/var/log/...
  • 1. 内存 top: 可动态查看各个进程占用CPU和MEM   vmstat:查看cpu使用总和 ...这个也和top的负载有关系,一般负载超过了3就比较高,超过了5就高,超过了10就不正常了,服务器的状态很危险 top的负载
  • java性能影响因素

    2013-08-24 15:52:27
    3.启动时间:程序从运行到可以正常处理业务需要花费多少时间 4.负载承受能力:当系统压力上升时,系统的执行速度、响应时间的上升曲线是否平缓 性能参考指标: 1.执行时间:一段代码从开始运行到运行结束,所用的...
  • 现代的操作系统为了最大利用内存,在内存中存放了缓存,因此内存利用率100%并不代表内存有瓶颈,衡量系统内有有瓶颈主要靠SWAP(与虚拟内存交换)交换空间利用率,一般情况下,SWAP交换空间利用率要低于70%,太多的...
  • 入门学习Linux常用必会60个命令实例详解doc/txt

    千次下载 热门讨论 2011-06-09 00:08:45
    文件为doc版,可自行转成txt,在手机上看挺好的。 本资源来自网络,如有纰漏还请告知,如觉得还不错,请留言告知后来人,谢谢!!!!! ...入门学习Linux常用必会60个命令实例详解 ...Linux提供了大量的命令,利用它...
  • 晶振两边的电容:晶振的标称值在测试时有一个“负载电容”的条件,在工 作时满足这个条件,振荡频率才与标称值一致。一般来讲,有低负载电容(串 联谐振晶体),高负载电容(并联谐振晶体)之分。在电路上的特征为:...
  • 也不需要关心它如何做负载均衡、如何实现网络加速,所以 CDN 对前端来说是 Serverless。再比如对象存储,和 CDN 一样,我们只需要将文件上传到对象存储,就可以直接使用了,不需要...
  • 必须通过额外的nginx做负载均衡 - 客户端的代码极其冗余,因为业务数据是需要融合的,很多页面需要发送多次请求才能返回给用户一个完成的View,再加上UI 的Callback hell,特别酸爽 - 将...
  • - process.uptime() 正常运行的时长 - process.memoryUsage() 内存使用情况 - process.cwd() 当前目录 - process.exit() 退出进程 - process.on() 添加事件监听 比如:on('uncaughtException') <h2>...

空空如也

空空如也

1
收藏数 20
精华内容 8
关键字:

内存负载多少正常