如何在CVM上监控CPU的使用情况

介绍

内存量,缓存大小,读取和写入磁盘的速度以及处理能力的速度和可用性都是影响基础架构性能的关键因素。在本教程中,我们将重点介绍CPU监控概念以及警报策略。我们将介绍如何使用两个常见的Linux实用程序,uptime命令和top命令了解CPU负载和利用率,以及如何设置腾讯云警报策略以通知您有关CVM CPU的高负载情况。

准备

我们讨论的两个工具,uptimetop在大多数Linux发行版都是默认安装。本文将以腾讯云CVM为例,没有服务器的同学可以在这里购买,不过我个人更推荐您使用免费的腾讯云开发者实验室进行试验,学会安装后在购买服务器。要利用警报策略等腾讯云功能,您需要启用监控的腾讯云 CVM。

背景

在我们深入研究uptimetop以及腾讯云监控的细节之前,我们需要学会如何判断CPU的占用率以及CPU的相关资料。

CPU负载与CPU利用率

CPU负载和CPU利用率是查看计算机处理能力使用的两种不同方式。

为了概念化两者之间的主要区别,我们可以将处理器想象为杂货店中的收银员和客户。CPU负载就像有一条结账线,客户在等待收银员空闲。负载是在线人数的计数,包括收银机的人数。线越长,等待的时间越长。相比之下,CPU利用率只关注收银员的忙碌程度,并且不知道有多少客户排队等候。

更具体地说,任务排队以使用服务器的CPU。当一个人到达队列的顶部时,它被安排接收一定量的处理时间。如果完成,则退出;否则它将返回队列的末尾。在任何一种情况下,下一个任务都可以轮到你了。

CPU负载是计划任务队列的长度,包括正在处理的任务。任务可以在几毫秒内切换,因此负载的单个快照不如在一段时间内获得的几个读数的平均值有用,因此负载值通常作为负载平均值提供。

CPU负载告诉我们CPU时间的需求量。高需求可能导致争用CPU时间和性能下降。另一方面,CPU利用率告诉我们CPU的繁忙程度,而不知道有多少进程在等待。监控利用率可以显示长期趋势,突出峰值,并帮助识别不需要的活动,

非标准化值与标准化值

在单处理器系统上,总容量始终为1。在多处理器系统上,数据可以以两种不同的方式显示。无论处理器数量如何,所有处理器的总容量都计为100%,这称为标准化。另一种是将每个处理器统计为一个单元,以便完全使用的双处理器系统容量为200%,完全使用的4处理器系统容量为400%,依此类推。

为了正确解释CPU负载或使用数据,我们需要知道服务器有多少处理器。

显示CPU信息

我们可以使用带有--all选项的nproc命令来显示处理器的数量。如果没有--all标志,它将显示当前进程可用的处理单元数。

nproc --all
2

在数现代Linux发行版中,我们还可以使用lscpu命令,该命令不仅显示处理器的数量,还显示体系结构,型号名称,速度等等:

lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-26xx v4
Stepping:              1
CPU MHz:               2394.454
BogoMIPS:              4788.90
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              4096K
NUMA node0 CPU(s):     0
Flags:fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rd rand hypervisor lahf_lm abm 3dnowprefetch bmi1 avx2 bmi2 rdseed adx xsaveopt

了解处理器的数量对于了解不同工具的CPU相关输出实际意味着什么非常重要。

负载和利用的最佳值是什么?

最佳CPU利用率取决于服务器预期的工作类型。持续的高CPU使用率是以与系统响应性较低的代价为代价的。通常,计算密集型应用程序和批处理作业始终以满容量或接近满容量运行。但是,如果期望系统提供网页或为SSH等服务提供响应式交互式会话,则可能需要一些空闲处理能力。与性能一样,了解系统上服务的特定需求和监控意外更改是优化资源的关键。

监控CPU

有许多工具可以提供对系统CPU状态的深入了解。我们将看两个命令,uptimetop。两者都是大多数流行的Linux发行版的默认安装的,并且通常按需使用以调查CPU负载和利用率。在下面的示例中,我们将测试上面描述的单核CVM。

uptime

我们将从uptime命令开始查看CPU负载,虽然只显示基本的CPU负载平均值,但在系统对交互式查询响应缓慢时可能会有所帮助,因为它只需要很少的系统资源。

upime显示了以下内容:

  • 命令运行时的系统时间
  • 服务器运行了多长时间
  • 用户对机器的连接数
  • 过去一分钟,五分钟和十五分钟的CPU负载平均值。
 uptime
 16:25:55 up 17 min,  1 user,  load average: 0.01, 0.02, 0.01

在此示例中,uptime命令在16:25分运行,系统已经运行了17分钟。uptime运行时连接了一个用户。由于此服务器有1个CPU,因此在运行命令之前的一分钟内,CPU负载平均值为0.01这意味着在该分钟内,一个进程正在使用CPU且没有进程在等待。5分钟的平均负载表明,对于某个时间间隔,大约98%的时间内处理器都处于空闲。15分钟的值表示可用的处理时间更多。这三个数字共同显示过去十五分钟内的负荷增加。

uptime提供了对平均负载的有用了解,但为了获得更深入的信息,我们将转向top。

top

uptime一样,top和Linux系统都可以使用top,但除了显示预设历史间隔的平均负载之外,它还提供定期的实时CPU使用信息以及其他相关的性能指标。和uptime不同在uptime运行后会自动退出,top会停留在前台,并定期刷新。

摘要块

top

The Header Block 前五行提供有关服务器上进程的摘要信息:

top - 16:30:42 up 21 min,  1 user,  load average: 0.00, 0.00, 0.00
Tasks: 108 total,   2 running, 106 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   885080 total,   552788 free,    71820 used,   260472 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   661344 avail Mem
  • 第一行几乎与uptime输出相同。就像uptime显示一分钟,五分钟和十五分钟的平均负载一样。此行与输出之间的唯一区别是该行uptime的开头显示命令名称top,并且每次top刷新数据时更新时间。
  • 第二行提供了任务状态的摘要:进程总数,在运行,休眠,停止或无响应的情况下有多少进程。
  • 第三行告诉我们CPU利用率。这些数字被标准化并显示为百分比(没有%符号),因此无论CPU数量多少,此行上的所有值都应加起来为100%。
  • 第四行和第五行分别告诉我们有关内存和交换使用情况的信息。

最后,摘要块后面是一个表格,其中包含有关每个单独过程的信息,我们稍后会查看。

我们来看另一个例子,在下面的示例摘要块中,一分钟的负载平均值超过了处理器的数量.77,这表示一个短暂的队列和稍微等待的时间。CPU使用的总容量为100%,并且有足够的可用内存。

top - 14:36:05 up 23:22,  2 users, load average: 2.77, 2.27, 1.91
Tasks: 117 total,   3 running, 114 sleeping,   0 stopped,   0 zombie
%Cpu(s): 98.3 us,  0.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.2 si,  1.3 st
KiB Mem :  4046532 total,  3244112 free,    72372 used,   730048 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  3695452 avail Mem
 . . . 

让我们更深入地了解CPU线上的每个字段:

  • us,user:时间运行un-niced的用户进程此类别是指在没有显式调度优先级的情况下启动的用户进程。更具体地说,Linux系统使用nice命令设置进程的调度优先级,因此“un-niced”表示nice不用于更改默认值。usernice值占代表所有用户进程。此类别中的高CPU使用率可能表示失控进程,您可以使用进程表中的输出来确定是否是这种情况。
  • sy,system:运行内核进程的时间大多数应用程序都有用户和内核组件。当Linux内核执行进行系统调用,检查权限或代表应用程序与设备交互之类的操作时,此处将显示内核对CPU的使用。当一个进程正在进行自己的工作时,它将出现在上面描述的user值中,或者如果使用nice命令显式设置其优先级,则会出现在下面的nice值中。
  • ni,nice:时间运行niced的用户进程user一样,这指的是不涉及内核的进程任务。与user不同这些任务的调度优先级是明确设置的。进程的niceness级别在摘要NI下的进程表的第四列中指示。值介于1和20之间且耗费大量CPU时间的进程通常不是问题,因为具有正常或更高优先级的任务将能够在需要时获得处理能力。但是,如果在-1和-20之间具有提升的良好性的任务占用了不成比例的CPU,则它们很容易影响系统的响应性并需要进一步调查。请注意,许多以最高调度优先级(-19或-20)运行的进程(取决于系统)由内核生成,以执行影响系统稳定性的重要任务。如果您不确定您看到的进程,那么应该检查而不是消除它们。
  • id,idle:在内核空闲处理程序中花费的时间该值表示CPU可用和空闲的时间百分比。当userniceidle值组合接近100%时,系统通常处于相对于CPU的良好工作状态。
  • wa,IO-wait:等待I / O完成的时间 IO-wait值显示处理器何时开始读取或写入活动并等待I/O操作完成。NFS和LDAP等远程资源的读/写任务也将计入IO-wait。与idle时间一样,这里的尖峰值是正常的,但是在这种状态下任何类型的频繁或持续时间都表明设备速度慢或存在潜在的硬盘问题而导致任务效率低。
  • hi:服务硬件中断这是从外围设备(如磁盘和硬件网络接口)发送到CPU的物理中断所花费的时间。当硬件中断值很高时,其中一个外围设备可能无法正常工作。
  • si:服务软件中断所花费的时间 软件中断由进程而不是物理设备发送。与CPU级别发生的硬件中断不同,软件中断发生在内核级别。当软件中断值使用大量处理能力时,请调查使用CPU的特定进程。
  • st:管理程序从此虚拟机管理系统(vm)中窃取时间“窃取”值是指虚拟CPU在虚拟机管理程序为自身或其他虚拟CPU提供服务时等待物理CPU所花费的时间。本质上,此字段中的CPU使用量表示您的VM可以使用多少处理能力,但是由于物理主机或其他虚拟机正在使用它,因此您的应用程序无法使用该处理能力。一般来说,在短时间内看到高达10%的盗窃价值并不值得关注。更长时间的大量窃取可能表明物理服务器对CPU的需求超出了它的支持。

现在我们已经查看了top标头块中提供的CPU使用情况摘要,我们将看一下它下面显示的进程表,注意特殊的CPU列。

进程表

在任何状态下,服务器上运行的所有进程都列在摘要块下面。以下示例包括上一节top命令中的进程表的前六行。默认情况下,进程表按%CPU排序,因此我们会首先看到占用CPU最多的进程。

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 1565 root      20   0  359332  11884   3816 S  0.3  1.3   0:03.00 barad_agent
 6690 root      20   0       0      0      0 S  0.3  0.0   0:00.03 kworker/u2:2
    1 root      20   0   37884   5952   4024 S  0.0  0.7   0:02.32 systemd
    2 root      20   0       0      0      0 S  0.0  0.0   0:00.00 kthreadd
    3 root      20   0       0      0      0 S  0.0  0.0   0:00.12 ksoftirqd/0
    5 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 kworker/0:0H
    7 root      20   0       0      0      0 S  0.0  0.0   0:00.28 rcu_sched
    8 root      20   0       0      0      0 S  0.0  0.0   0:00.00 rcu_bh
    9 root      rt   0       0      0      0 S  0.0  0.0   0:00.00 migration/0
   10 root      rt   0       0      0      0 S  0.0  0.0   0:00.00 watchdog/0
   11 root      20   0       0      0      0 S  0.0  0.0   0:00.00 kdevtmpfs
   12 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 netns
   13 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 perf
   14 root      20   0       0      0      0 S  0.0  0.0   0:00.00 khungtaskd
   15 root       0 -20       0      0      0 S  0.0  0.0   0:00.00 writeback
   16 root      25   5       0      0      0 S  0.0  0.0   0:00.00 ksmd
​

CPU%以百分比值表示,但没有标准化,进程表中所有值的总和应该加起来为100%。

注意: 如果您希望看到如果您是多核系统,CPU百分比加起来可能不是100%。要想标准化值,可以按SHIFT + I,显示屏将从Irix模式切换到Solaris模式。这将显示相​​同的信息,在服务器的CPU总数中平均,以便使用的数量不会超过100%。当我们切换到Solaris模式时,我们会收到Irix模式关闭的简短消息,压力的值将从每个近100%切换到每个约50%。

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
10081 sammy     20   0    9528     96      0 R 50.0  0.0   0:49.18 stress
10082 sammy     20   0    9528     96      0 R 50.0  0.0   0:49.08 stress
 1439 root      20   0  223832  27012  14048 S  0.2  0.7   0:11.07 snapd
    1 root      20   0   39832   5868   4020 S  0.0  0.1   0:07.31 systemd

到目前为止,我们已经学会了两个常用于查看CPU负载和CPU利用率的Linux命令。在下一节中,我们将介绍可用的CPU监控工具,腾讯云 CVM无需付额外费用。

腾讯云云监控监控CPU利用率

腾讯云云监控是一项针对云资源进行监控的服务,可实时监控您的腾讯云云产品资源,提取云产品关键指标,以监控图表形式展示,是所有云产品的监控运维总入口。您可以在这里查看并使用最全、最详细的监控数据。

云监控服务主要用图表化信息帮助您了解云产品资源使用率、应用程序性能和云产品运行状况,告警推送消息帮助用户第一时间发现业务异常。让用户无需额外开发成本,就能全面掌控云产品资源使用、运行情况。比如我想监控自己服务器的CPU指标,那么我可以按照下面的教程。

查看CPU利用率

首先打开云监控的页面,然后点击云产品监控,由于我们监控的是腾讯云CVM的CPU情况,那么我选择云服务器

选中我们想要查看的服务器,我们将会看到CPU近期的详细使用记录,您可以选择近24小、近7天的数据进行对比。

同时,您也可以在这个页面查看内存、内网带宽、外网带宽、分区使用量、等信息。

设置告警策略

我们也可以自定义告警策略,点击面板左侧的“我的告警”,然后选择“告警策略”,我们看到默认已经有两个告警策略。

默认策略为“硬盘只读,告警”和“ping不可达告警”。里面没有“CPU使用过高告警”,所以我们需要新建告警。点击左侧的新增选择您告警策略,所属项目,以及触发条件。

这样,当您的CPU使用超过90%时,系统将自动发送告警到您的邮件,微信,手机。

结论

在这篇文章中,我们已经学会使用uptimetop两个常见的Linux实用程以提供深入了解CPU的Linux系统,以及如何使用腾讯云云监控查看CVM上的历史CPU利用率,并提醒您更改和告警情况。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏FreeBuf

如何使用Cron Jobs实现Linux提权

今天给各位渗透测试同行们提供一种Linux提权方法,在这篇文章中,我们将介绍如何使用Cron Jobs来实现Linux下的权限提升,并获取远程主机的root访问...

30200
来自专栏精讲JAVA

关于业务架构的一些思考

公司是典型的SOA架构,Web层之下就是远程Service。Web层负责调用Service,Service则在内部整合缓存、数据库等内容,实现业务逻辑。

15040
来自专栏FreeBuf

快讯 | macOS的快速浏览缓存可能会泄露加密数据

macOS的快速浏览机制允许用户在不需要实际打开文件的情况下查看文件的内容,但研究人员Wojciech Reguła表示,这个功能很可能泄露缓存文件的信息,即使...

12500
来自专栏趣谈编程

TCP 协议简介

(图片说明:TCP 是以太网协议和 IP 协议的上层协议,也是应用层协议的下层协议。)

15500
来自专栏京东技术

Flutter图片缓存 | Image.network源码分析

Android高级工程师,6年以上开发经验,有丰富的代码重构和架构设计经验,负责京东商城我的京东的开发工作,热衷于学习和研究新技术。

3.2K20
来自专栏mySoul

Node.js多进程

使用子进程的执行命令,缓存子进程的输出。并将子进程的输出以回调函数参数的形式进行返回

18000
来自专栏程序猿DD

TCP之三次握手四次挥手

TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。

202100
来自专栏IT派

用 Python 实现每秒处理 120 万次 HTTP 请求

用 Python 做到每秒处理上百万次 HTTP 请求,可能吗?也许不能,但直到最近,这已成为现实。

24130
来自专栏web前端教室

【飞起】手把手教你如何前端页面秒开!!

没有最快,只有更快!世上武功,唯快不破!新能源汽车百公里加速4.x秒!...,可以说,人类对于速度的追求是永无止境的。在网页上也是一样,网页打开的速度快点,再快...

19730
来自专栏IT派

【PHP框架】 Laravel vs Yii2 到底哪个是未来?

性能和速度,一个框架的趋势,绝对不是因为这两个因素决定的,会有很小的影响,这当然了,不过不会有太大的影响。

37400

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励