彻底理解CPU Load-这一篇就够了

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了彻底理解CPU Load-这一篇就够了相关的知识,希望对你有一定的参考价值。

参考技术A

我们经常去看Linux的平均负载。通过 uptime 或者 top 命令就可以显示出,平均负载的内容如下:

大多数人都对平均负载有所了解:三个数字分别代表了一分钟,五分钟和十五分钟三个时间段内的CPU负载的平均值,而数字越低越好。数字越高表示系统出现了问题或机器过载。但是负载值多少才最合适?谁也说不清楚。

首先,我们从最简单的单核处理器的系统进行说明。

单核CPU就像一条单行道。想象您是一名交警.有时这条单行道太忙了,有汽车在排队等待同行。想让人们知道这条路的交通如何。最直接的指标是就是 在特定时间内,这条道路上等待多少辆汽车 。如果没有汽车在等待,即将到来的驾驶员便知道他们可以马上驶过。如果有汽车在排队等候,则驾驶员就知道知道要耽误时间了。

所以,交警同志,你应该怎样去定义交通拥塞程度的?可以按照下面的规则:

这基本上就是CPU负载的含义。 “汽车”是指使用CPU时间(“通行”)或排队使用CPU的进程。 Unix将CPU负载定义为运行队列的长度:当前正在运行的进程数与正在等待(排队)的进程数之和。

就像交警一样,您希望您的汽车/进程永远不会等待。因此,理想情况下,您的CPU负载应保持在1.00以下。如果系统的负载暂时获得高于1.00的峰值,还是可以的,但是负载您始终高于1.00时,则需要进行处理了。

其实不然,当CPU的 load为1.00的时候,你的系统处于满负荷运转,再来一个进程,就会高于1.00,你的系统的性能将会降低,所以系统没有流出 余粮 ,实际工作中,很多系统管理员认为比较理想的CPU负载应该是 0.7 ,因此我们针对线上CPU负载的处理规则如下:

对于四处理器系统,3.00的负载表示比较健康。

在多处理器系统上,负载是相对于可用处理器核心数量的。在单核系统上,“ 100%利用率”表示负载为1.00,在双核系统上是2.00,在四核系统上是4.00,依此类推。

如果再回到交通问题上,“ 1.00”实际上意味着“一个车道的交通承载量”。在单车道上,这意味着它已被填满。在单向双车道上,负载为1.00表示其交通容量只有50%时-只有一个车道占用,因此还有另一个完整车道可以使用。

与CPU相同:在单核服务器上1.00的负载表示CPU利用率为100%。在双核服务器上,负载为2.00才代表100%CPU使用率。

出于性能目的,具有单个双核处理器的计算机是否基本上等同于具有两个具有一个内核的处理器的计算机?是的。大致上是一样的。但是还有很多其他微妙之,例如:高速缓存的数量,处理器之间的进程切换频率等。尽管多处理器有这些优点,但为了对于CPU负载值来说,CPU Core的总数是很重要的,因为无论怎样CPU Core是物理隔离的。

因此我们需要添加两条新的CPU 负载处理规则:

我们看下 uptime 命令的输出:

这是在双核CPU的系统上运行的,所以,我们的负载还有很大的空闲资源。在负载达到并保持在1.4左右之前,我不需要做处理。
现在,那三个数字什么含义呢? 0.65是最近一分钟的平均值,0.42是最近五分钟的平均值,而0.36是最近15分钟的平均值。这使我们想到了一个问题:

我应该观察哪个平均值? 1、5或15分钟?

根据我们前面讨论过的处理规则(1.00 =进行处理,依此类推),您应该查看5或15分钟的平均值。坦白说,若一分钟的CPU 负载值达到1,还是可以的。但是若15分钟的负载平均值都在1.0以上,那么你需要进行干预和处理了。(当然,对于多核处理器的系统,该值将变为1.0*CPU核心数目)。
因此,核数对于解释平均负载非常重要.我如何知道我的系统有多少个核?

cat /proc/cpuinfo 可以获得系统的CPU信息。
若只想得到CPU核数,可以运行: grep \'model name\' /proc/cpuinfo | wc -l

理解 Python 装饰器看这一篇就够了

讲 Python 装饰器前,我想先举个例子,虽有点污,但跟装饰器这个话题很贴切。

每个人都有的内裤主要功能是用来遮羞,但是到了冬天它没法为我们防风御寒,咋办?我们想到的一个办法就是把内裤改造一下,让它变得更厚更长,这样一来,它不仅有遮羞功能,还能提供保暖,不过有个问题,这个内裤被我们改造成了长裤后,虽然还有遮羞功能,但本质上它不再是一条真正的内裤了。于是聪明的人们发明长裤,在不影响内裤的前提下,直接把长裤套在了内裤外面,这样内裤还是内裤,有了长裤后宝宝再也不冷了。装饰器就像我们这里说的长裤,在不影响内裤作用的前提下,给我们的身子提供了保暖的功效。

谈装饰器前,还要先要明白一件事,Python 中的函数和 Java、C++不太一样,Python 中的函数可以像普通变量一样当做参数传递给另外一个函数,例如:

def foo():
    print("foo")

def bar(func):
    func()

bar(foo)

正式回到我们的主题。装饰器本质上是一个 Python 函数或类,它可以让其他函数或类在不需要做任何代码修改的前提下增加额外功能,装饰器的返回值也是一个函数/类对象。它经常用于有切面需求的场景,比如:插入日志、性能测试、事务处理、缓存、权限校验等场景,装饰器是解决这类问题的绝佳设计。有了装饰器,我们就可以抽离出大量与函数功能本身无关的雷同代码到装饰器中并继续重用。概括的讲,装饰器的作用就是为已经存在的对象添加额外的功能。

先来看一个简单例子,虽然实际代码可能比这复杂很多:

def foo():
    print(‘i am foo‘)

现在有一个新的需求,希望可以记录下函数的执行日志,于是在代码中添加日志代码:

def foo():
    print(‘i am foo‘)
    logging.info("foo is running")

如果函数 bar()、bar2() 也有类似的需求,怎么做?再写一个 logging 在 bar 函数里?这样就造成大量雷同的代码,为了减少重复写代码,我们可以这样做,重新定义一个新的函数:专门处理日志 ,日志处理完之后再执行真正的业务代码

def use_logging(func):
    logging.warn("%s is running" % func.__name__)
    func()

def foo():
    print(‘i am foo‘)

use_logging(foo)

这样做逻辑上是没问题的,功能是实现了,但是我们调用的时候不再是调用真正的业务逻辑 foo 函数,而是换成了 use_logging 函数,这就破坏了原有的代码结构, 现在我们不得不每次都要把原来的那个 foo 函数作为参数传递给 use_logging 函数,那么有没有更好的方式的呢?当然有,答案就是装饰器。

简单装饰器

def use_logging(func):

    def wrapper():
        logging.warn("%s is running" % func.__name__)
        return func()   # 把 foo 当做参数传递进来时,执行func()就相当于执行foo()
    return wrapper

def foo():
    print(‘i am foo‘)

foo = use_logging(foo)  # 因为装饰器 use_logging(foo) 返回的时函数对象 wrapper,这条语句相当于  foo = wrapper
foo()                   # 执行foo()就相当于执行 wrapper()

use_logging 就是一个装饰器,它一个普通的函数,它把执行真正业务逻辑的函数 func 包裹在其中,看起来像 foo 被 use_logging 装饰了一样,use_logging 返回的也是一个函数,这个函数的名字叫 wrapper。在这个例子中,函数进入和退出时 ,被称为一个横切面,这种编程方式被称为面向切面的编程。

@ 语法糖

如果你接触 Python 有一段时间了的话,想必你对 @ 符号一定不陌生了,没错 @ 符号就是装饰器的语法糖,它放在函数开始定义的地方,这样就可以省略最后一步再次赋值的操作。

def use_logging(func):

    def wrapper():
        logging.warn("%s is running" % func.__name__)
        return func()
    return wrapper

@use_logging
def foo():
    print("i am foo")

foo()

如上所示,有了 @ ,我们就可以省去foo = use_logging(foo)这一句了,直接调用 foo() 即可得到想要的结果。你们看到了没有,foo() 函数不需要做任何修改,只需在定义的地方加上装饰器,调用的时候还是和以前一样,如果我们有其他的类似函数,我们可以继续调用装饰器来修饰函数,而不用重复修改函数或者增加新的封装。这样,我们就提高了程序的可重复利用性,并增加了程序的可读性。

装饰器在 Python 使用如此方便都要归因于 Python 的函数能像普通的对象一样能作为参数传递给其他函数,可以被赋值给其他变量,可以作为返回值,可以被定义在另外一个函数内。

*args、**kwargs

可能有人问,如果我的业务逻辑函数 foo 需要参数怎么办?比如:

def foo(name):
    print("i am %s" % name)

我们可以在定义 wrapper 函数的时候指定参数:

def wrapper(name):
        logging.warn("%s is running" % func.__name__)
        return func(name)
    return wrapper

这样 foo 函数定义的参数就可以定义在 wrapper 函数中。这时,又有人要问了,如果 foo 函数接收两个参数呢?三个参数呢?更有甚者,我可能传很多个。当装饰器不知道 foo 到底有多少个参数时,我们可以用 *args 来代替:

def wrapper(*args):
        logging.warn("%s is running" % func.__name__)
        return func(*args)
    return wrapper

如此一来,甭管 foo 定义了多少个参数,我都可以完整地传递到 func 中去。这样就不影响 foo 的业务逻辑了。这时还有读者会问,如果 foo 函数还定义了一些关键字参数呢?比如:

def foo(name, age=None, height=None):
    print("I am %s, age %s, height %s" % (name, age, height))

这时,你就可以把 wrapper 函数指定关键字函数:

def wrapper(*args, **kwargs):
        # args是一个数组,kwargs一个字典
        logging.warn("%s is running" % func.__name__)
        return func(*args, **kwargs)
    return wrapper

带参数的装饰器

装饰器还有更大的灵活性,例如带参数的装饰器,在上面的装饰器调用中,该装饰器接收唯一的参数就是执行业务的函数 foo 。装饰器的语法允许我们在调用时,提供其它参数,比如@decorator(a)。这样,就为装饰器的编写和使用提供了更大的灵活性。比如,我们可以在装饰器中指定日志的等级,因为不同业务函数可能需要的日志级别是不一样的。

def use_logging(level):
    def decorator(func):
        def wrapper(*args, **kwargs):
            if level == "warn":
                logging.warn("%s is running" % func.__name__)
            elif level == "info":
                logging.info("%s is running" % func.__name__)
            return func(*args)
        return wrapper

    return decorator

@use_logging(level="warn")
def foo(name=‘foo‘):
    print("i am %s" % name)

foo()

上面的 use_logging 是允许带参数的装饰器。它实际上是对原有装饰器的一个函数封装,并返回一个装饰器。我们可以将它理解为一个含有参数的闭包。当我 们使用@use_logging(level="warn")调用的时候,Python 能够发现这一层的封装,并把参数传递到装饰器的环境中。

@use_logging(level="warn")等价于@decorator

类装饰器

没错,装饰器不仅可以是函数,还可以是类,相比函数装饰器,类装饰器具有灵活度大、高内聚、封装性等优点。使用类装饰器主要依靠类的__call__方法,当使用 @ 形式将装饰器附加到函数上时,就会调用此方法。

class Foo(object):
    def __init__(self, func):
        self._func = func

    def __call__(self):
        print (‘class decorator runing‘)
        self._func()
        print (‘class decorator ending‘)

@Foo
def bar():
    print (‘bar‘)

bar()

functools.wraps

使用装饰器极大地复用了代码,但是他有一个缺点就是原函数的元信息不见了,比如函数的docstring__name__、参数列表,先看例子:

# 装饰器
def logged(func):
    def with_logging(*args, **kwargs):
        print func.__name__      # 输出 ‘with_logging‘
        print func.__doc__       # 输出 None
        return func(*args, **kwargs)
    return with_logging

# 函数
@logged
def f(x):
   """does some math"""
   return x + x * x

logged(f)

不难发现,函数 f 被with_logging取代了,当然它的docstring__name__就是变成了with_logging函数的信息了。好在我们有functools.wrapswraps本身也是一个装饰器,它能把原函数的元信息拷贝到装饰器里面的 func 函数中,这使得装饰器里面的 func 函数也有和原函数 foo 一样的元信息了。

from functools import wraps
def logged(func):
    @wraps(func)
    def with_logging(*args, **kwargs):
        print func.__name__      # 输出 ‘f‘
        print func.__doc__       # 输出 ‘does some math‘
        return func(*args, **kwargs)
    return with_logging

@logged
def f(x):
   """does some math"""
   return x + x * x

装饰器顺序

一个函数还可以同时定义多个装饰器,比如:

@a
@b
@c
def f ():
    pass

它的执行顺序是从里到外,最先调用最里层的装饰器,最后调用最外层的装饰器,它等效于

f = a(b(c(f)))

 

以上是关于彻底理解CPU Load-这一篇就够了的主要内容,如果未能解决你的问题,请参考以下文章

彻底理解CPU Load-这一篇就够了

彻底掌握Xcode CoreData调试技巧看这一篇就够了

彻底掌握Xcode CoreData调试技巧看这一篇就够了

彻底理解大数据 HDFS 分布式文件系统,这篇就够了

你想快速掌握数据库中间件 MyCAT 的核心概念吗,读这一篇就够了!

深入理解JavaScript,这一篇就够了