agent17(agent)

什么是 agent?

作者：边际

转自：人机与认知实验室

如涉版权请联系编辑微信 @iwish89

哲学园鸣谢

Agent的概念由Minsky在其1986年出版的《思维的社会》一书中提出。Minsky认为社会中的某些个体经过协商之后可求得问题的解，这些个体就是Agent。他还认为Agent应具有社会交互性和智能性。从此，Agent的概念便被引入人工智能和计算机领域，并迅速成为研究热点。Agent技术在上世纪90年代成为热门话题,甚至被一些文献称为软件领域下一个意义深远的突破,其重要原因之一在于,该技术在基于网络的分布计算这一当今计算机主流技术领域中,正发挥着越来越重要的作用。一方面,Agent技术为解决新的分布应用问题提供了有效途径;另一方面,Agent技术为全面准确地研究分布计算系统的特点提供了合理的概念模型。

在分布计算领域,人们通常把在分布式系统中持续自主发挥作用的、具有以下特征的活着的计算实体称为Agent。

1. 自主性

Agent具有属于其自身的计算资源和局部于自身的行为控制机制,能够在没有外界直接操纵的情况下,根据其内部状态和感知到的环境信息,决定和控制自身的行为。例如,SNMP中的agent就是独立运行在被管理单元上的自主进程。

2. 交互性

Agent能够与其他Agent(包括人),用Agent通信语言实施灵活多样的交互,能够有效地与其他Agent协同工作。例如,一个Internet上的用户需要使用Agent通信语言向主动服务Agent陈述信息需求。

3. 反应性

Agent能够感知所处的环境(可能是物理世界,操纵图形界面的用户,或其他Agent等),并对相关事件作出适时反应。例如,一个模拟飞机的Agent能够对用户的操纵作出适时反应。

4. 主动性

Agent能够遵循承诺采取主动行动,表现出面向目标的行为。例如,一个Internet上的主动服务Agent,在获得新的信息之后能够按照约定主动将其提交给需要的用户;一个工作流管理Agent,能够按照约定将最新的工作进展情况主动通报给有关的工作站。

具有上述特性的计算实体可以是类Unix进程(或线程)、计算机系统、仿真器、机器人。从系统实现的层次上分析,在上面列举的应用中,纯软件形态的Agent就是指具有上述特性的类Unix进程。在上述4个特性中,前3个是基本的。人们也称具有上述前3个特性的计算实体为反应式Agent。在经典的客户/服务器计算模型中,服务器就是一种典型的反应式Agent。一些学者对Agent概念赋予了更拟人化的要求,例如分布式人工智能领域的学者,要求Agent具有知识、信念、意图等认知特性;CSCW领域的学者,要求Agent具有更友好的人-机交互方式。当然,目前在主流的分布计算领域为人们广泛认同的Agent概念,是具有上述4个特性的计算实体。

结构

当初,人们在研究并发计算的过程中,为了刻划若干个同时处于执行过程中的计算单位,引入了\"进程\"的概念,并逐步形成了具有特定技术内涵的进程结构。当今,人们在研究分布计算的过程中发现,分布式系统中广泛存在着用已有的计算机概念难以准确描述的自主行为实体,于是引入了\"Agent\"的概念。因此研究Agent的体系结构成为分布计算领域的重要课题。

Agent的体系结构是指构造Agent的特殊方法学,它描述了组成Agent的基本成分及其作用、各成分的联系与交互机制、如何通过感知到的内外部状态确定Agent应采取的不同行动的算法,以及Agent的行为对其内部状态和外部环境的影响等等。目前,人们已提出的Agent的体系结构大致可分为以下三类。

1. 审慎式体系结构(Deliberative Architecture)

该体系结构的特点是Agent中包含了显式表示的世界符号模型,Agent的决策是通过基于模板匹配和符号操作的逻辑(或准逻辑)推理作出的,如同人们通过\"深思熟虑\"后作出决定一样,因此被称为审慎式的体系结构。该体系结构在(分布式)人工智能领域占主导地位。我们可以认为构造经典的基于知识的系统,就是按照这种体系结构构造Agent的雏形的。因此,也可以说该体系结构的存在与现代人工智能的历史一样长。

2. 反应式体系结构(Reactive Architecture)

该体系结构的特点是Agent中包含了感知内外部状态变化的感知器、一组对相关事件作出反应的过程,和一个依据感知器激活某过程执行的控制系统,Agent的活动是由于受到内外部某种\"刺激\"而发生的,因此被称为反应式的体系结构。该体系结构在目前主流的分布式系统中占主导地位。本文列举的分布式应用中所涉及的Agent基本上是反应式体系结构。

我们甚至可以认为一个计算机基本系统,也是一个按照这种体系结构构造的Agent的雏形。

因此,也可以说该体系结构的存在与现代计算机系统的历史一样长。

3. 混合式体系结构(Hybrid Architecture)

该体系结构的特点是Agent中包含了审慎式和反应式两个子系统,通常这两个子系统是分层次的,前者建立在后者的基础之上。这种体系结构的研究与实验目前在人工智能领域较为活跃,我们认为有关成果将对分布式系统中Agent应用功能的增强产生直接影响。例如,已经有研究工作在模拟飞行员的Agent中加入基于符号表示和推理的各种规划与决策能力,以提高模拟飞行员的适应性。

目前,我们正在研究开发一种具体的反应式Agent体系结构。在该结构中,Agent由事件处理系统、方法集和内部状态集三个主要成分构成。其中,事件处理系统是Agent的行为控制系统。Agent的活性表现为它的事件处理系统,在该Agent的生命期内始终持续自主地工作着。在该结构中,事件是与Agent有特定关联的特殊状态(如外部某服务请求到达、内部某特定状态被修改或超过设定的阈值等)。事件处理系统涉及事件感知、事件适配和事件处理分发3个环节的活动。Agent的事件感知器时刻捕捉其所关注的事件状态的出现,并根据事件状态的类型启动相应的事件适配器工作;事件适配器获取相关事件信息作识别,并将识别结果提交给相应的事件处理分发器,启动有关的事件处理方法执行。Agent的方法集体现了该Agent事件处理能力的成分,描述了Agent处理相关事件的方法。方法的执行由事件处理分发器引发,在其执行过程中可能影响Agent的内部状态,从而导致新事件的发生。Agent的内部状态集是表现该Agent当前状态的成分,其中包括表征事件的状态。在Agent的行为过程中,该Agent的内部状态可能会不断发生变化。

Agent之间的消息传递机制通过消息事件的处理实现。假设Agent A具有消息事件的处理能力,其接收服务请求的典型工作过程如下:一个传递给A的服务请求导致消息事件的发生。A的(消息)事件感知器将及时检测该事件的发生,从而引发A的(消息)事件适配器接收此消息;消息事件适配器按照Agent之间的消息传递协议,分析识别该消息为服务请求类型,进而引发A的(请求)事件处理分发器,并将有关适配信息提交给该分发器;(请求)事件处理分发器则根据适配信息选择相应的服务方法执行。

Agent的事件处理机制不仅可以有效地实现客户/服务器计算中传统的客户直接请求/服务器被动服务的机制,而且为实现Agent之间以及Agent与外部环境之间更为主动灵活的交互机制奠定了基础。例如,通过定义特定的故障事件,使担负系统管理的Agent能够主动向Manager报告关键故障的发生,甚至独自处理故障;通过定义特定的时钟事件,可以实现Agent之间以及Agent与用户之间的定时服务;通过定义特定的内部状态修改事件,实现Agent之间共有信息副本的一致性维护;通过定义特定的信息查询事件,使Agent在收到与查询相关的信息后,主动向信息需求者提供信息服务等等。

Agent技术环境

如同主流操作系统都提供了多进程的并发系统开发和运行环境一样,为多Agent的分布式应用系统的运行开发和建立分布计算环境也日显重要。按照此类环境承诺的Agent的体系结构分类,相关的支持环境也可分为三大类。

1. 面向审慎式体系结构的支持环境

此类支持环境通常建立在知识系统支持技术和主流网络计算技术的基础上,进一步提供了Agent程序设计语言和Agent通信语言等工具。

2. 面向反应式体系结构的支持环境

此类支持环境通常建立在分布式对象技术的基础上。因为反应式Agent的体系结构与对象的结构存在很大的相似性,利用带有专门控制器的对象可以实现反应式Agent。在此类支持环境中提供各种控制器的框架,以及基于框架的Agent定义与生成工具。

3. 面向混合式体系结构的支持环境

此类支持环境可以建立在层次化的分布式对象技术和知识系统技术的基础上。

从主流的分布计算术技术和应用角度分析,我们认为发展分布式对象技术对多Agent应用系统的支持,将是一项十分有意义的工作。我们正在研究如何在ORB(对象请求中介)技术的基础上,通过纵向或横向扩展实现主动服务机制,使其在分布式对象环境中能够方便地实现具有自主性、交互性、反应性和主动性的Agent。

Agent技术影响

一个新的概念和技术在计算机领域能够引起广泛关注,甚至\"火\"起来,通常是由于以下因素所至:

(1)它在解决计算机主流技术及其应用的瓶颈问题上提供了有效的途径。

(2)它在开拓计算机技术新的应用领域方面发挥了关键的作用。

进入80年代,个人计算机和工作站的普及以及网络通信技术的迅速发展,使拥有个人计算机或工作站的广大用户,迫切需要共享或集成分布于网络上的丰富信息资源,用以廉价获得超出局部计算机能力的高品质服务,并逐步实现计算机支持的协同工作。在这样的需求驱动下,分布计算成为影响当今计算机技术发展的关键技术力量。分布计算术目前还处于客户/服务器计算的中间阶段,由于受到新的应用需求的冲击,开始向分散对等的协同计算方向发展,将Agent的概念和技术引入分布计算已成为这一发展阶段的重要特征。

从逻辑上讲,一个分布式系统可以定义为由多个相互作用的Agent组成的系统,各种分布式系统的差异主要表现为其中Agent的角色和交互方式上的差别。例如分布式客户/服务器系统是这样的分布式系统,其中的Agent或为客户或为服务器,交互关系仅限于客户主动请求/服务器被动服务的交互方式。然而,这种基于Agent的分布式系统观使人们跳出了客户/服务器系统的局限,适应了应用需求的发展。从发展的角度看,我们认为,\"Agent\"的概念在分布计算术中的地位和作用,可以与\"进程\"的概念在并发计算中的地位和作用相类比。

问题

目前,常规的分布计算术是基于经典的客户/服务器计算模型的,即将分布式应用分解为客户和服务器两大部分,服务器只有在接到客户的请求后方能提供服务。这些技术是在共享分布资源的应用背景下形成的,在解决新的分布式应用方面存在诸多局限性。从以下几个目前人们较为关心的分布式应用需求中,我们不难发现问题所在。

1. 从\"人找信息\"到\"信息找人\"

目前绝大多数的Internet应用是建立在客户/服务器计算模型基础上的,这就使得通过Internet进行信息分布和查找的应用不可避免地存在以下问题:一方面,信息提供者不能适时地将信息主动提供给最需要的用户;另一方面,信息使用者不知道到哪里能够找到急需的信息。越来越多的人开始为Internet上形形的庞杂信息所累,\"逛\"Internet的感觉真有点象逛商业街的感觉:疲劳、茫然;需要的东西不知道在何处寻找,不需要的东西却强烈地冲击人们的视野。盲目被动的搜寻导致网上流动的有效信息占有率大大降低,使已经十分紧俏的网络带宽被浪费。人们希望服务器能够根据客户的需求主动提供信息,实现\"信息找人\"。然而,常规的分布计算技术却难以胜任,原因之一就是经典的客户/服务器计算技术不支持主动服务机制。

2. 并行工程

尽管现代企业在其产品设计制造过程的诸多环节上,卓有成效地采用了各种计算机辅助工具,但各环节之间仍存在着数据共享和部门协同的沟痕,影响了产品设计制造的整体进度和质量。为此,人们提出了并行工程(CE)的概念,其核心思想就是以分布式的企业计算环境为基础设施,实现产品设计制造全过程以及相关资源的优化组合,使各部门最大限度地协同工作,减少中间环节对产品设计制造的进度和质量的影响。然而,常规的分布计算技术同样难以胜任此类协同工作的应用。因为经典的客户/服务器计算技术不支持服务器对客户的直接控制,也不支持客户应用之间直接的群体感知。

3. 分布式交互仿真

仿真器早已在教育、训练、制造和娱乐等诸多领域的应用中显示出其重要的价值。但是单一仿真器的应用局限性很大,例如孤立的军用仿真器,不能适应现代战争环境对武器系统综合效能分析的需要,或对战斗人员进行接近战场环境训练的要求。为了更好地发挥现有仿真器的作用,减少训练费用,美国国防部支持了称为分布式交互仿真(DIS)的研究,其初衷是将各类仿真器和计算机通过网络连接起来,在此基础上建立虚拟的战场环境,以提高仿真训练的实效性。显然,常规的分布计算技术更难以胜任此类应用。因为,DIS中的行为实体是不能简单地用\"客户\"和\"服务器\"两类角色来刻划的。

概括地讲,常规的分布计算技术的局限源于经典的客户/服务器计算模型的局限,即: 将分布式应用中的自主行为实体简单地划分为\"客户\"和\"服务器\"两类; 客户与服务器之间的交互关系仅限于客户主动请求/服务器被动响应的非对等关系。

Agent技术应用

Agent的概念和技术出现在分布式应用系统的开发之中,并表现出明显的实效性。以下列举几项人们在分布式应用方面所从事的涉及Agent的研究和开发工作,从中我们可以初步体会到Agent概念和技术的意义。

1. 利用Agent技术改善Internet应用

例如,研制\"信息找人\"的Agent。它具有\"需求\"与\"服务\"的集散能力,它接受信息分布者有关信息要点的注册,以及信息查询者有关信息需求要点的注册。该Agent根据这些信息,主动通知用户谁能够提供其所需信息,或主动通知信息提供者谁目前需要其所能提供的信息。

2. 利用Agent技术实现并行工程的思想

例如,利用Agent技术开发工作流管理者。它能够向各工作站下达工作流程和进度计划,主动引导各工作站按照工作流程和进度计划推进工作,受理并评价各工作站工作进展情况的报告,以及集中管理各类数据等等。

3. 利用Agent技术开发分布式交互仿真环境

例如,将飞行训练仿真器与计算机网络上的若干工作站连接起来,在工作站上实现多个模拟飞机的Agent,与仿真器构成可交互的空战仿真环境。受训人员操作这种置于交互仿真环境中的仿真器,不仅能够体验各种操纵飞机的技能,而且能够通过与智能化的自主模拟战机的交互,实践各种空战战术行为(单一飞行训练仿真器能支持前者,但不能支持后者)。

实际上,Agent的概念并非是今天才出现在分布计算领域的,它在分布式系统自身的管理中早已被使用了。例如,在80年代形成的基于TCP/IP的互联网络管理技术SNMP中就采用了manager/agent模型。在该模型中,agent是运行在被管理单元上的自主行为实体,它能够对被管理单元上的相关事件作出反应、响应manager发来的管理命令等等。然而直到今天,Agent的概念和技术在分布计算领域才引起人们的重视,因为它在解决当今分布式应用面临的普遍问题上产生了实际效果。

性能分析-CPU

要点关注哪些CPU指标。如何定位CPU相关性能问题。一些常见问题分析。基本概念load值

平均负载值表示了对CPU资源的需求，是根据正在运行的进程数(使用率)和正在排队的进程数(饱和度)计算得出。在Linux下，不可中断状态(D)，也会计入平均负载值，如执行磁盘IO。当load值超过CPU数量，则表示CPU饱和。当load值达到CPU数量的70%时，系统就可能会出现响应变慢。

注：不可中断状态，表示进程正在和硬件进行交互。为了保护进程数据和硬件的一致性，系统不允许其他进程或中断打断该进程，一般情况下，该状态持续时间较短。

nice值

进程优先级值，取值范围为-20~+19，值越小，优先级越高。

使用率

单位时间内CPU的繁忙情况的统计，与平均负载(load值)不一定完全对应。因为平均负载(load值)的统计，包含了运行进程和不可中断进程，也就是说，当进程处理不可断状态时，会计入平均负载，但是不计入使用率。

用户时间

执行用户态应用程序代码的时间。计算密集型应用程序，会把大量时间用在用户态代码。

系统时长

执行内核态代码的时间，包括系统调用、内核线程和中断时间。IO密集型应用程序，系统调用频率较高，通过执行内核代码进行IO操作。

进程上下文切换

分为自愿上下切换和非自愿上下文切换。

自愿上下文切换(cswch)：进程无法获取所需资源，导致上下文切换。比如，IO、内存等资源不足。

非自愿上下文切换(nvcswch)：由于时间片已到等原因，被系统强制调度，进而发生的切换。比如，大量进程都在争抢CPU。

常见场景：时间片耗尽、资源不足被挂起、进入sleep、优先级调度、中断等。

中断

中断是指处理器接收到来自硬件或软件信号，提示内核发生了某个事件。可以分为硬中断和软中断两种。

硬中断(上半部)是由硬件触发的，中断cpu当前正在处理的任务，执行少量的重要操作，最后发送一个软中断信号。如：网卡接收数据时，把网卡的数据读到内存中。

软中断(下半部)是由内核触发，通常以内核线程方式运行。被软中断信号唤醒后，执行未完成的工作。包括内核调度、cpu锁、网络收发、定时等。如：从内存中找到网络数据，并将其交给应用程序。

在linux系统下，可以看到ksoftirqd 进程，则为软件中断处理程序，中断的处理过程会导致上下文的切换。

CPU缓存

CPU中一般包含多个层次的缓存，CPU缓存一般有L1、L2和L3(可选)三级。访问速度：L1>L2>L3，其中，L1分为指令缓存和数据缓存；L1和L2缓存通常是每个CPU核独占，而L3缓存通常是在CPU槽内所有核共享。

CacheLine(高速缓存行)

高速缓存行由有效位(1位)、标记位(t位)和缓存块(b位)三个部分组成。高速缓存的结构将m个地址位划分为t个标记位、s个组索引和b个块偏移位。根据其映射关系分：直接映射(每组一行)、组相联(每组多行)和全相联(只有一个组)。

分析工具proc

使用watch 能看到各中断变化情况，如：/proc/softirqs。

# watch -d cat /proc/softirqsEvery 2.0s: cat /proc/softirqs Tue May 11 23:48:19 2021 CPU0 HI: 1 TIMER: 765274325 NET_TX: 0 NET_RX: 307335014 BLOCK: 70948692BLOCK_IOPOLL: 0 TASKLET: 16 SCHED: 0 HRTIMER: 0 RCU: 763596087

关键字段含义为：

TIMER：定时任务。NET_TX：网络发送。NET_RX：网络接收。SCHED：内核调度。RCU：RCU锁。uptime

查看机器平均负载值。

# uptime 16:31:14 up 184 days, 19:40, 1 user, load average: 0.01, 0.03, 0.05

最后三个数字是1、5和15分钟内的平均负载。

vmstat

统计虚拟内存信息，包括系统范围的cpu平均负载。

# vmstat 1procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 7 0 0 95588 142780 1482732 0 0 13 36 2 2 1 1 99 0 0 0 0 0 95324 142780 1482732 0 0 0 116 446 1013 2 1 95 2 0 0 0 0 95944 142780 1482732 0 0 0 0 607 1563 0 0 100 0 0

输出的第一行是系统启动以来的总结信息，Linux上的r列是显示的当前值。重点输出列如下：

r：运行队列长度：可运行线程的总数，包括运行状态和不可中断状态的进程数。b：处于不可中断状态下的进程数。cs：每秒上下文切换次数，这个值包括，系统调用时上下文切换、线程切换等。us：用户态时间。sy：系统态时间(内核)。cs：每秒进程上下文切换次数。id：空闲。wa：等待IO，即线程被阻塞等待磁盘IO时的CPU空闲时间。bi：块设备读取。bo：块设备写入。mpstat

统计每个CPU的信息。

# mpstat -P ALL 1Linux 3.10.0-1062.9.1.el7.x86_64 (VM_0_3_centos) 2021年05月11日 _x86_64_ (1 CPU)16时56分15秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle16时56分16秒 all 1.00 0.00 2.00 1.00 0.00 0.00 0.00 0.00 0.00 96.0016时56分16秒 0 1.00 0.00 2.00 1.00 0.00 0.00 0.00 0.00 0.00 96.00

重点输出列如下：

CPU：逻辑CPU ID，或者ALL表示总结信息。%user：用户态时间。%nice：以nice优先级运行的进程用户态时间。%sys：系统态时间。%iowait：IO等待。%irq：硬件中断CPU。%soft：软件中断CPU。%idle：空闲。sar

查看CPU相关的历史统计信息。

# sar -n DEV 1Linux 3.10.0-1062.9.1.el7.x86_64 (VM_0_3_centos) 2021年05月12日 _x86_64_ (1 CPU)10时47分13秒 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s10时47分14秒 eth0 5.15 4.12 0.27 0.89 0.00 0.00 0.0010时47分14秒 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.0010时47分14秒 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s10时47分15秒 eth0 3.95 3.95 0.21 1.07 0.00 0.00 0.0010时47分15秒 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.0010时47分15秒 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s10时47分16秒 eth0 7.22 6.19 0.39 2.00 0.00 0.00 0.0010时47分16秒 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00IFACE：表示网卡。rxpck/s：每秒接收的网络帧数。txpck/s：每秒发送的网络帧数。rxkB/s：每秒接收的字节数，单位：kB。txkB/s：每秒发送的字节数，单位：kB。ps

进程状态的细节信息，包括CPU用户统计信息。

# ps auxUSER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMANDroot 1 0.0 0.1 51788 3072 ? Ss 2020 20:03 /usr/lib/systemd/systemd --switched-root --system --deserialize 22root 2 0.0 0.0 0 0 ? S 2020 0:07 [kthreadd]

具体列信息，参考man ps ，重点列如下：

PID：进程号。%CPU：进程所占用的cpu百分比。%MEM：进程所占用的内存百分比。VSZ：进程所占用的虚拟内存大小。RSS：进程所占用的实际内存大小。STAT：进程状态，R：正在运行或等待运行；S：可中断状态，等待被唤醒；D：不可中断状态，一般处于正在和硬件交互；T：暂停状态或跟踪状态，表示该进程已经停止执行；Z：僵尸进程；I：空闲状态；X：退出状态，进程即将销毁。top

监控每个进程/线程的CPU信息。

# toptop - 17:07:23 up 184 days, 20:16, 1 user, load average: 0.00, 0.01, 0.05Tasks: 87 total, 2 running, 85 sleeping, 0 stopped, 0 zombie%Cpu(s): 0.0 us, 6.2 sy, 0.0 ni, 93.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 stKiB Mem : 1882056 total, 89844 free, 162580 used, 1629632 buff/cacheKiB Swap: 0 total, 0 free, 0 used. 1532220 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4018 root 20 0 953996 27264 12024 S 6.7 1.4 13:03.90 YDService 1 root 20 0 51788 3072 1720 S 0.0 0.2 20:03.97 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:07.38 kthreadd 4 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H 6 root 20 0 0 0 0 S 0.0 0.0 7:55.19 ksoftirqd/0 7 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0

可以通过top 命令下的f 指令，查看各字段含义。

pidstat

按每个进程/线程，输出CPU信息，包括用户态和系统态时间 的分解。默认情况下，仅输出活动进程信息。

# pidstat -w -u 1Linux 3.10.0-1062.9.1.el7.x86_64 (VM_0_3_centos) 2021年05月11日 _x86_64_ (1 CPU)17时16分21秒 UID PID %usr %system %guest %CPU CPU Command17时16分22秒 0 4018 0.00 1.02 0.00 1.02 0 YDService17时16分22秒 0 4035 1.02 0.00 0.00 1.02 0 YDEdr17时16分21秒 UID PID cswch/s nvcswch/s Command17时16分22秒 0 1 1.02 0.00 systemd17时16分22秒 0 6 7.14 0.00 ksoftirqd/017时16分22秒 0 9 68.37 0.00 rcu_sched17时16分22秒 0 1942 1.02 0.00 sshd17时16分22秒 0 4070 2.04 0.00 YDLive17时16分22秒 0 5430 1.02 0.00 pidstat17时16分22秒 0 6844 8.16 0.00 kworker/0:117时16分22秒 0 24919 2.04 0.00 tmux17时16分22秒 0 29496 1.02 0.00 barad_agent17时16分22秒 0 29501 3.06 0.00 barad_agent17时16分22秒 0 30085 10.20 0.00 redis-server17时16分22秒 0 30089 10.20 0.00 redis-server17时16分22秒 0 30091 10.20 0.00 redis-servertime

统计运行命令，并输出运行时间信息。

# time ./a.outreal 0m0.003suser 0m0.002ssys 0m0.000sreal：程序执行时间。user：用户态执行时间。sys：用户态执行时间。perf

cpu性能收集，通过perf生成火焰图，找出代码热点。

查看top

# perf top -g -p 9712

采样热点

# perf record -g -p 9712# perf report生成火焰图

火焰图生成工具，Flame Graph项目位于GitHub上：https://github/brendangregg/FlameGraph。

1、对perf采样的数据文件进行解析：perf script -i perf.data &> perf.unfold2、将perf.unfold中的符号进行折叠：./stackcollapse-perf.pl perf.unfold &> perf.folded3、生成svg图：./flamegraph.pl perf.folded > perf.svgpstack

查看进程的调用堆栈。

# pstack 4018Thread 23 (Thread 0x7f9043e78700 (LWP 4020)):#0 0x000000000075dc0a in ?? ()#1 0x0000000000782b1a in ?? ()#2 0x00000000000000f7 in ?? ()#3 0x0000000000000001 in ?? ()#4 0x0000000000000fc3 in ?? ()#5 0x000000c000355620 in ?? ()#6 0x0000000001000004 in ?? ()#7 0x000000000077ae8b in ?? ()#8 0x000000c00020eb40 in ?? ()#9 0x0000000000000000 in ?? ()……

在碰到cpu使用率很小，疑似进程死锁时，通过该命令，可以找到死锁的调用堆栈。但是该命令也有一定的局限性，当该进程没有带符号表时，无法看到其具体地堆栈信息。

strace

跟踪进程的调用链，可以跟踪到进程的系统调用，包括参数、返回值及执行时间等信息。

# strace -Ff -Ttt -p 4070strace: Process 4070 attached with 7 threads[pid 4079] 18:53:36.216102 futex(0xc000112848, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>[pid 4078] 18:53:36.216179 futex(0xd28380, FUTEX_WAIT_PRIVATE, 0, NddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddULL <unfinished ...>[pid 4077] 18:53:36.216186 futex(0xc000112148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>[pid 4074] 18:53:36.216192 futex(0xd28278, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>[pid 4073] 18:53:36.216197 futex(0xc000030848, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>[pid 4072] 18:53:36.216203 restart_syscall(<... resuming interrupted futex ...> <unfinished ...>[pid 4070] 18:53:36.216210 epoll_pwait(5, [], 128, 0, NULL, 16149789) = 0 <0.000061>[pid 4070] 18:53:36.216308 epoll_pwait(5, ^Cstrace: Process 4070 detached

常用的命令参数：

-c：统计每一系统调用的执行时间、次数和出错的次数等。-f：跟踪由调用fork所产生的子进程。-F：跟踪由调用vfork所产生的子进程。-t：在输出中的每一行前加上时间信息。-tt：在输出中的每一行前加上时间信息，微秒级。-ttt：微秒级输出。-T：显示每个调用所消耗的时间。-o filename：将strace输出写入文件filename。-p pid：跟踪指定pid进程。

需要注意的是，strace 没有内容输出时，并不表示该进程发生阻塞，可能当前正在执行的操作并不存在系统调用。这一点可以通过进程当前状态来确定。

分析策略

1、检查系统中整体CPU利用率，单个CPU的利用率(如：top、mpstat等)。

2、确认系统负载受限于CPU，确认系统并发程度，是否为单线程，线程数是多少，是否设置容器限制(如：mpstat等)。

3、量化系统中CPU使用量百分比，找出使用率高的进程，并确认系统在用户态和内核态的使用情况(如：top、pidstat等)。

4、如果是内核态占比较高，则对系统调用、上下文切换、中断等方面，进行频率和数量的统计，如有必要可以考虑用kprobes定制工具，以便获取更多上下文信息(如：kprobes、/proc/softirqs等)。

5、如果是用户态占比较高，则使用性能剖析器来采样应用程序的调用栈信息，再用CPU火焰图来展示，如有必要可以考虑用uprobes定制工具(如：perf等)。

6、使用PMC测量每个时钟周期内的CPU指令执行量。(如：bpftrace、systemtap等)。

常见问题load值过高

当load值超过CPU核数的70%时，可以认为该指标异常。通常的排查思路：

1、使用mpstat -P ALL 5 判断出，该问题的原因，是算力不足还是IO等待。

2、使用pidstat -u 5 1 判断出是哪个进程导致。

3、通过pstack查看调用堆栈，strace跟踪进程的调用，或者使用perf查看该进程的热点代码。

%usr过高

用户态cpu使用率过高，一般是由于应用程序计算量过大导致。排查思路：

1、使用perf 找出代码热点，做进一步分析。

2、应用程序没有符号表信息时，可以考虑使用strace 跟踪进程的系统调用，并结合相关日志进行分析。

3、需要注意的是，如果有服务频繁重启，也可能导致CPU使用率过高，需要具体分析。

%system过高

内核态CPU使用率过高，一般是由于系统调用、中断等导致。排查思路：

1、查看中断数、系统调用情况等。

2、使用perf 找出代码调用链，做进一步分析。

%iowait过高

iowait升高时，可能是进程因为得不到硬件响应，而处于不可中断状态。

1、通过top命令查看哪些进程处于不可中断状态，状态标识为：D。

2、通过pidstat -d 1 10 -p 9720 确认当进程的读写情况。

3、使用strace或perf，跟踪进程的系统调用情况。

中断过高

当单个CPU的中断次数过1w，可以认为中断数偏高，排查思路：

1、使用watch -d cat /proc/interrupts 和watch -d cat /proc/softirqs ，分别查看中断信息。

2、找出变化幅度最大的指标，做进一步分析。

进程上文切换频繁

通过pistat -wt 可以看到每个进程及子线程的上下文切换情况；上文切换分为：自愿切换(cswch)和非自愿切换(nvcswch)。

自愿切换(cswch)过高：考虑IO、内存等系统资源不足。

非自愿切换(nvcswch)过高：考虑大量进程竞争cpu、中断、系统调用、时间片、优先级等因素。

cacheline命中率低

CPU中cacheline的命中率，对程序的性能有着很重要地意义。在做性能优化时，可以参考该指标进行有针对性的优化。

使用perf查看命中情况

# perf stat -B -e cache-references,cache-misses,cycles,instructions,branches,faults,migrations sleep 5 Performance counter stats for 'sleep 5': 17,262 cache-references 5,506 cache-misses # 31.897 % of all cache refs 1,634,376 cycles 721,565 instructions # 0.44 insn per cycle 140,824 branches 178 faults 1 migrations 5.001432881 seconds time elapsed使用valgrind --tool=cachegrind 查看命中情况

# valgrind --tool=cachegrind ./a.out==9129== Cachegrind, a cache and branch-prediction profiler==9129== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote et al.==9129== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info==9129== Command: ./a.out==9129==--9129-- warning: L3 cache found, using its data for the LL simulation.^C==9129====9129== Process terminating with default action of signal 2 (SIGINT)==9129== at 0x400518: main (loop.cpp:10)==9129====9129== I refs: 66,818,498==9129== I1 misses: 769==9129== LLi misses: 761==9129== I1 miss rate: 0.00%==9129== LLi miss rate: 0.00%==9129====9129== D refs: 33,204,531 (33,091,924 rd + 112,607 wr)==9129== D1 misses: 8,410 ( 7,036 rd + 1,374 wr)==9129== LLd misses: 6,149 ( 5,037 rd + 1,112 wr)==9129== D1 miss rate: 0.0% ( 0.0% + 1.2% )==9129== LLd miss rate: 0.0% ( 0.0% + 1.0% )==9129====9129== LL refs: 9,179 ( 7,805 rd + 1,374 wr)==9129== LL misses: 6,910 ( 5,798 rd + 1,112 wr)==9129== LL miss rate: 0.0% ( 0.0% + 1.0% ) 进程CPU使用率很低，服务无响应

该现象说明，CPU当前未工作，进程处于资源等待状态。可以通过pstack命令，查看进程当前调用堆栈分析原因。大多数情况是，执行过程发生了阻塞等待，如死锁等。

参考

《Systems Performance:Enterprise and Cloud》

《BPF Performance Tools》

《Computer Systems》

《Modern Operating Systems》

http://www.brendangregg/linuxperf.html