精华内容
下载资源
问答
  • 内存负载多少正常
    千次阅读
    2017-06-29 10:51:20
    项目中常会遇到系统安装完后一切正常,但应用上线后,系统出现不明原因的死机或缓慢。我们就必须分析到底是硬件还是软件的问题?通常,我是使用下面的两个工具帮忙进行负载测试,会比较容易定位问题的原因。

    1、Memtester

    先解压到某个目录,然后进去make all,会生成一个memtester文件的,然后运行:
    【./memtester 2048 1】
    2048表示测试的内存大小,单位是M,1表示次数。
    如果2048不接受的,把它缩小就可以了。先运行一次,如果没有问题就把次数增加即可。
    监控:vmstat、top都可以看到。
    下载: 点击

    2、cpuburn-in

    这是测试cpu的,解压后,直接运行:
    【./cpuburn-in 1】
    1表示1分钟,没有问题的话,就运行30分钟或1440分钟(24小时)。
    下载: 点击

    更多相关内容
  • linux 查看负载和使用情况 top

    千次阅读 2021-01-12 11:19:20
    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上运行或者等待运行多少进程)的平均进程数。如果一个进程满足以下条件则其就会位于运行队列中:- 它没有在等待I/O操作的结果- 它没有主动进入...

    一、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

    在理解了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

    RUSERReal user name

    UID进程所有者的用户id

    USER进程所有者的用户名

    GROUP进程所有者的组名

    TTY启动进程的终端名。不是从终端启动的进程则显示为 ?

    PR优先级

    NInice值。负值表示高优先级,正值表示低优先级

    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

    三、调试

    在查看了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。

    展开全文
  • linux系统下查看CPU、内存负载情况

    千次阅读 2014-10-13 15:40:32
    如果swpd的值不为0,或者比较大,比如超过了100m,只要si、so的值长期为0,系统性能还是正常 free 当前的空闲页面列表中内存数量(k表示) buff 作为buffer cache的内存数量,一般对块设备的读写才需要缓冲。 cache...
    $ 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  4 329796  26040   4528 3379824    1    1    50   160   36   17  2 10 85  3  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)
     
    
    欢迎关注我的微信公众号: JavaQ

         

    
    
    展开全文
  • 宝塔面板负载状态经常是 100%,内存使用率也是 100%,CPU 也不用说了,现在将我使用的一个非常有效的方法分享给大家,希望对大家有用。 首先进入宝塔面板,然后打开软件管理,找到你正在使用的 php 版本,然后点...
  • 电脑内存两个G,刚开机的时候内存使用率在多少才算正常,我的电脑一开机就在30%以上正常吗?
  • 当然了,除了使用性价比高的设备和专用负载分流设备外,还有一些其他选择来帮你解决此问题,就是搭建集群服务器通过整合多台普通的服务器设备并以同一个地址对外提供相同的服务,今天杰哥就带领大家学习企业中常用的...
  • 四层LVS与七层Nginx负载均衡的区别

    千次阅读 2022-01-12 03:31:08
    一、四层负载均衡与七层负载均衡: (1)四层负载均衡: 四层负载均衡工作在 OSI 七层模型的第四层(传输层),指的是负载均衡设备通过报文中的目标IP地址、端口和负载均衡算法,选择到达的目标内部服务器,四...
  • Linux操作系统负载的命令查看与详解

    千次阅读 多人点赞 2022-06-07 19:05:33
    在平常的工作与生活中,衡量服务器的性能是每一个程序员必备的技能,load作为必不可少的衡量性能的指标,它的理解和查看是非常重要的,本文主要介绍load(负载)的常用查看命令与定义:负载(load)是linux机器的一个...
  • 图解负载负载太高如何解决

    千次阅读 2020-03-08 09:48:41
    50 ~ 90% - 服务器负载正常,用户的请求可以及时得到服务器响应 90% ~ 100% - 表示服务器资源已耗尽,无法及时响应用户请求,需尽快排查项目是否运行异常,或增加服务器配置 影响服务器负载的因素: 1、CPU使用率 2...
  • Kafka负载均衡策略

    千次阅读 2021-02-05 09:40:34
    分区器是生产者层面的负载均衡。Kafka 生产者生产消息时,根据分区器将消息投递到指定的分区中,所以 Kafka 的负载均衡很大程度上依赖于分区器。 Kafka 默认的分区器是 Kafka 提供的 DefaultPartitioner。它的分区...
  • linux下进行简单的CPU和内存负载测试

    千次阅读 2013-04-24 10:33:33
     项目中常会遇到系统安装完后一切正常,但应用上线后,系统出现不明原因的死机或缓慢。我们就必须分析到底是硬件还是软件的问题?通常,我是使用下面的两个工具帮忙进行负载测试,会比较容易定位问题的原因。 1、...
  • 关于F5负载均衡你认识多少

    万次阅读 多人点赞 2018-06-09 18:01:09
    负载均衡知多少网络负载均衡(load balance),就是将负载(工作任务)进行平衡、分摊到多个操作单元上进行执行,例如web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。...
  • 网上有详细的解释,这属于正常现象~~~Linux/Unix系统管理内存的方式和windows是不一样的,即便是一个负载很小的linux,跑几天后,内存占用量也将达到90%以上,即便无人访问,这个数字是完全正常的。但是,这个内存...
  • 系统设计基础 负载均衡

    千次阅读 2021-01-25 15:06:05
    二、负载均衡分类软件负载均衡硬件负载均衡DNS负载均衡三、负载均衡算法1. 健康检测(health checks)2. 负载均衡如何处理状态3. 负载均衡器如何选择后端服务器?随机轮询加权轮询IP哈希最小连接数一致性 Hash粘性...
  • 1、获取cpu占用情况 [root@localhost utx86]# top -n 1 |grep Cpu Cpu(s): 1.9%us, 1.3%sy, 0.0%ni, 95.9%id, 0.6%wa, 0.1%hi, 0.2%si, 0.0%st ...2、获得内存占用情况 [root@localhost utx86]# ...
  • 腾讯云ELB负载均衡(blance)

    千次阅读 2021-01-06 23:42:27
    负载均衡(Elastic Load Balancer)提供安全快捷的流量分配服务,它可以无缝提供分配应用程序流量所需的负载均衡容量,以实现自动分配云中多个 CVM 实例间应用程序的访问流量,让您实现更高水平的应用程序容错...
  • Nginx-负载均衡

    万次阅读 2021-05-31 01:41:27
    NGINX负载均衡Ngnix-负载均衡基本配置报文头修改行为服务器获取真实客户端IPProxy中的buffer行为QuestionProxy cache行为Proxy_cache指令Request Tracing负载均衡的参数连接限制 limit_req根据客户端IP...通过仅向正常
  • 下面内容是具体的原理分析:在分析负载为什么高之前先介绍下什么是负载、多任务操作系统、进程调度等相关概念。 什么是负载 什么是负载负载就是cpu在一段时间内正在处理以及等待cpu处理的进程数之和的统计信息,...
  • 负载均衡器/LB - 学习/实践

    千次阅读 2022-03-14 00:23:55
    缺点有: 更新不及时:DNS缓存的时间比较长,修改DNS配置后,由于缓存的原因,还是有很多用户会继续访问修改前的IP,这样的访问会失败,达不到负载均衡的目的,并且也影响用户正常使用业务。 扩展性差:DNS负载均衡...
  • linux进程管理(二十五)—负载均衡

    千次阅读 2022-01-29 22:05:52
    linux进程管理—负载均衡 前面主要是学习进程的调度管理,默认都是在单CPU上的调度策略,在O(1)调度后,为了减小CPU之间的干扰,就会为每个CPU上分配一个任务队列,运行的时候可能会出现有的CPU很忙,有的CPU很闲,...
  • 平常的工作中,在衡量服务器的性能时,经常会涉及到几个指标,load、cpu、mem、qps、rt等。每个指标都有其独特的...本文,主要来介绍一下一个比较重要的指标——机器负载(Load),主要涉及负载的定义、查看负载方...
  • 负载均衡与双机热备

    千次阅读 2018-11-17 19:11:40
    负载均衡原理与技术实现 负载均衡(Load Balance,简称LB)是一种服务器或网络设备的集群技术。负载均衡将特定的业务(网络服务、网络流量等)分担给多个服务器或网络设备,从而提高了业务处理能力,保证了业务的高可用...
  • 微服务(Spring Cloud)——负载均衡

    千次阅读 2021-03-06 18:59:25
    负载均衡 组件库: Spring Cloud Netflix 组件库 组件: Ribbon 二、负载均衡介绍 (一)、什么是负载均衡 负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量...
  • 当您的网站或者APP用户访问量增多,一台服务器就会显得越来越不够用,这时候你会采取增加服务器台数的办法解决问题,而通常和增加服务器数量配套使用的还有“负载均衡”。那么负载均衡是什么?有什么用呢?蒙鸟云将...
  • 负载均衡SLB

    千次阅读 2021-04-25 13:11:55
    随着业务发展,我们对外提供的服务可能性能不达标,一台服务器可能无法满足业务的需求,为了解决这个问题,我们可能增加服务器的配置,但是服务器的配置(CPU,内存,硬盘)有上限,这时候就需要用到多台服务器提供同...
  • Nginx + Tomcat负载均衡集群

    千次阅读 2021-10-15 00:29:23
    目录引言一、案例概述二、环境部署 引言 通常情况下,一个 Tomcat 站点由于可能出现单点故障以及无法应付过多客户复杂多样的请求等问题...目前很多大型网站都应用 Nginx 服务器作为后端网站程序的反向代理及负载均衡器
  • 一大早收到运维同学反馈、线上某台机器cpu的负载达到了97%以上,为了不影响机器上服务的正常运行,急需找到导致负载过高的原因并将负载降到合理的区间
  • 2017-11-05发生的情况。BCC的CPU负载过高导致服务停了,但是内存用量正常。CPU使用率用了44分钟增长到了100%。如下图: 查了一下,提示的是"java.lang.OutOfMemoryError: Java heap space",如下图:
  • 【linux性能优化】平均负载的理解

    千次阅读 2021-06-02 23:43:31
    每次发现系统变慢时,通常做的第一件事就是执行top或者uptime命令,了解系统的负载情况 比如像下面这样,在命令行里输入了uptime命令,系统也随即给出了结果 uptime 02:34:03 up 2 days, 20:14, 1 user, load ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 163,700
精华内容 65,480
关键字:

内存负载多少正常