zoukankan      html  css  js  c++  java
  • CPU 性能分析

    相信有工作几年的测试人员,在做测试时,一发现测试环境卡顿,就会想着去看服务器运行状态。怎么看?

    可能大脑里第一反应就是用‘top’,执行 top 命令,看啥呢?

    你看这个,啥情况?有人能告诉我,为啥 CPU 使用率这么低,但是 load 值却比较高吗?

    不知道原因,但是,知道现在系统 load 值很高,所以服务器很卡。

    今天,我们就来给大家介绍下,怎么看服务器运行情况。

    首先,看服务器的运行情况,我们肯定会去看 CPU 的运行情况。当我们在执行 top 命令的时候,我们会看到有一个 %CPU(s) 这样一行,这一行,就是显示 CPU 的运行情况(默认间隔 3 秒钟更新数据),其中

    • us:用户态,未改变优先级的进程占用 CPU 的百分比

    • sy:系统态,内核空间占用 CPU 百分比

    • ni:用户态改变优先级的进程占用的 CPU 百分比

    • id:空闲的时间百分比

    • wa:空闲&等待 IO 的时间百分比

    • hi:硬中断时间百分比

    • si:软中断时间百分比

    • st:虚拟化时被其余 vm 窃取的时间百分比

    这些,我们得知道是什么意思。

    然后,我们还需要知道,按下数字键 ‘1’,就会看到 %Cpu(0)..... 这样多行,就可以知道当前有多少个活跃的 CPU(逻辑)。

    那么,接下来的问题就是这些数据分别代表什么意思?与 load 又是什么关系?

    要想弄明白这两个问题,我们得先知道 CPU 由哪些部分组成及他们之间是怎么工作的。

    很多人说,CPU 是由三个部分组成,其实,还不准确,准确来说,应该是由 4 个重要部分组成:计算器、控制器、寄存器和时钟

    • 计算器,顾名思义,就是 CPU 中进行运算的核心元件,CPU 实现的所有计算,都是由它来完成的。

    • 控制器,就是 CPU 的指挥控制中心,是管理者,做一些指挥调度工作。

    • 寄存器,这个买过电脑的同学应该都熟悉,现在买电脑 CPU 都要看有几级缓存,缓存大小。它是 CPU 中暂存数据的地方,待处理和已经处理的数据,都会暂存在这里。

    • 时钟,这个东西,你说它在吧,它又不在;不在吧,它又在。它做的就是时间片段计时的。计算器,在进行计算的时候,都是有个时间片段的,时间片段到了,不管计算是否完成,计算器,都得去干其他事情,之后,再分配时间片段,来做未完成的事情。时钟,就是这么霸道。

     这张图,相信很多同学都见过,非常形象的描述了 CPU 内部元件之间的关系。

    接下来,我们就来想一下你们公司的产品服务器,是不是在一台服务器上部署产品服务,服务运行起来,普通用户通过操作端,进行操作,从而驱动你们产品的服务进行计算,输出结果给用户。这个计算,就是在 CPU 内完成的。

    • 开发人员,在实现产品经理要求的功能时,就会写一些代码,这些代码,有的是要自身逻辑运算,有的是需要调系统底层能力支撑,调了系统底层的,我们说要使用系统内核,要用到 CPU 的 sy 系统态,不用调系统底层的,我们就说是用 CPU 的 us 用户态,

    • 从非内核进入内核,再从内核处理完出来到非内核,这是不是要来回的切换。就好比公司的核心保密区和非保密区,你要进进出出,是不是都有严格的审查。这个类比到 CPU,我们叫上下文切换。而这个切换,我们也分自愿上下文切换和非自愿上下文切换,这个大家应该很好理解,主动的进进出出就是自愿上下文,被迫进进出出就是非自愿上下文切换。还有我们前面说的时钟片段,这些,就与 CPU 的 si 软中断,和 CPU 的 hi 硬中断关联上了。

    • 在 CPU 进行计算时,你是不是要给一些资源(如:原始数据),进入 CPU,计算完之后,再把结果从 CPU 中转移出来,这个资源的进出,就是资源的 I/O,等待这些资源的时间,就是 CPU 的 wa 等待时间百分比。

    • 一台服务器并不会只部署一个应用服务,当有多个应用服务在运行时,你认为现在的服务器是让它们串行,还是并行?相信不用我说答案,大家都会说肯定是并行,那你们再想想,并行,插队是不是有可能。这种,服务间进程插队的情况,就是 CPU 的 ni 进程优先级切换。 

    • 当没有用户使用你们的产品的时候,服务器在歇息,次数就是 CPU 的 id 空闲时间百分比。

    好了,大家是否理解了呢?可以对照着第 1 张图,检验一下,看自己是否弄明白了哦!

    第二个问题,CPU 的数据与 load 值之间到底什么关系?load 值很大,CPU 的数据就一定高吗?

    相信,很多人,在没有看过文章第 1 张图之前,肯定会认为是对的,load 值大,CPU 的使用率就一定高。因为,普通的认识是,CPU 的 us + sy 的值越接近 100,说明 CPU 越繁忙,load 值就应该高,相反,就应该低。其实,在这个里面,存在一个误区。

    现在 Linux 服务器的内核,绝大多数都已经升级,超过了 2.6 版本。在 2.6 版的内核中,已经把 load 值的计算方法调整为,所有不可中断睡眠状态的进程,即 load average = CPU 负载 +Disk 负载 + 网络负载 + 其余外设负载,从第 1 张图看,就是包含了我们的 wa 等待负载值。

    所以,第 1 张图中,我们能分析出,目前的服务器存在 I/O 问题,是因为服务器频繁在执行数据换进换出,导致 CPU 的 wa 等待资源时间过长,从而出现 load 值过高,系统比较卡顿。

  • 相关阅读:
    ASP.NET没有魔法——ASP.NET MVC & 分层
    ASP.NET没有魔法——第一个ASP.NET应用《MyBlog》
    ASP.NET没有魔法——为什么使用ASP.NET
    ASP.NET没有魔法——开篇-用VS创建一个ASP.NET Web程序
    Orchard详解--第九篇 拓展模块及引用的处理
    【原创-算法-实现】异步HTTP请求操作
    000.Introduction to ASP.NET Core--【Asp.net core 介绍】
    新建 ASP.NET Core Web API 项目 -- RESTFul 风格 Hello World!
    新建 ASP.NET Core MVC 项目 -- Hello World!
    新建 .NET Core 项目 -- Hello World!
  • 原文地址:https://www.cnblogs.com/Nancy-Lee/p/14007335.html
Copyright © 2011-2022 走看看