如何在Silicon Cloud vServers上监控CPU使用

简介

假设您的网站或应用程序比平常更缓慢。您如何开始调查问题？慢应用的原因有很多种，但有时是因为您的服务器的CPU使用率达到了最大值。本指南将帮助您查明是否出现了这种情况。

我们将从了解 Linux 服务器上最常被引用的两个资源使用指标开始：CPU 利用率和负载平均值。我们将探讨这两个指标的区别，然后使用两个命令行工具（uptime 和 top）来查看它们的值。最后，我们将学习如何使用 Silicon Cloud 监控来追踪这些指标的变化，并设置警报策略，当指标超出正常值时通过电子邮件或 Slack 进行通知。

先决条件

要按照这个指南进行操作，你需要以下工具：

• A two-core Silicon Cloud vServer with Monitoring enabled. Read our documentation if you don’t know how to create a vServer. Also read the guide How To Install the Silicon Cloud Metrics Agent to learn how to enable Monitoring on your new vServer or add the Monitoring Agent to an existing vServer.
• The stress utility installed on your vServer. Use apt or dnf to install stress from your distribution’s repositories.

本指南中介绍的两个命令行实用工具——uptime和top，在大多数Linux发行版中都默认安装。

背景

在我们看如何检查和追踪 CPU 利用率和负载平均之前，让我们从概念上考虑一下它们。它们测量什么？

CPU 使用率与负载平均值

这两个经常检查的指标有时会混淆，因为它们都与CPU有关，并且当服务器明显过载时，两者都可能很高。但它们不测量相同的内容，它们也不总是直接相关。CPU利用率告诉您当前CPU有多繁忙，而负载平均值告诉您在最近的过去中，平均有多少任务等待或在CPU上运行。

想象一台服务器的CPU就像杂货店里的收银员，任务就像顾客。CPU负载是排队人数的总计，包括正在收银台服务的顾客。而CPU利用率则表示收银员的工作强度。

当然，这两个指标是相关的：一个明显的原因是如果商店的收银员过慢（或过少），那么收银台可能会长时间排队。但也可能因为其他原因出现排队问题。如果顾客要求对某件商品进行价格核查，收银员会请其他员工去处理。收银员可能在等待价格核查的同时继续扫描其他商品，但如果在其他商品扫描完成之前价格核查结果还没有得到返回（例如价格核查人员暂时离开），那么收银员和顾客将无所事事地等待，而队伍则会变长。这就像一个任务等待某个缓慢或不可用的 I/O 设备（比如硬盘），实际上，I/O 密集型的工作负载可能导致高负载平均值但低 CPU 利用率。

现在想象一下，价格检查员休息30分钟。与此同时，还有几位顾客需要价格检查。（假设空闲的收银员不能自己进行价格检查，就像CPU不能执行磁盘的功能一样。）收银员将所有这些顾客放在一边，继续处理其他客户，清空结账队列。现在收银员处于空闲状态（利用率为0%），但仍有几位顾客站在周围（非零负载），他们仍然需要她的时间，尽管她不能立即完成他们的结账，因为大家都在等待价格检查员的回来。对于收银员而言，有顾客需求，但她并不忙碌，所以如果有新的顾客接近收银台，他将会立即得到服务。

你可以想象其他令人等待时间增加的杂货店问题，这并不是收银员的错，但是考虑这些问题将使我们进入关于CPU利用率、负载平均值、I/O等待和CPU调度的更深入讨论。然而，这样的讨论超出了本指南的范围，所以现在只需要记住：

1. 负载平均值不是CPU利用率的代理。它们不是同一回事。

CPU负载意味着CPU需求。性能不足的CPU可能会增加这种需求，但其他情况也可能，比如I/O等待。负载平均值通常被认为是与CPU相关的指标，但它并不仅仅与CPU有关。因此，增加更多或更快的CPU并不能总是减轻高负载平均值的问题。

那么服务器是如何表示这些指标的？

计量单位

在系统中，CPU利用率以总CPU容量的百分比给出。在单处理器系统中，总CPU容量始终为100%。在多处理器系统中，容量可以用两种不同方式表示：归一化或非归一化。

标准化容量意味着将所有处理器的容量一起考虑为100%，而不考虑处理器的数量。如果两个处理器系统中的两个CPU都处于50%的利用率，那么标准化总利用率就是50%。

非规范化容量以百分之百作为每个处理器的计算单位，因此双处理器系统具有200%的容量，四处理器系统具有400%的容量，依此类推。如果双处理器系统中的两个中央处理器（CPU）的利用率均为50%，则非规范化总利用率为100%（即200%最大容量的一半），这可能会让人感到困惑，如果不明白你正在看一个双处理器系统上的非规范化数字的话。

负载平均数是一个十进制数，它代表了等待或正在被所有CPU服务的任务的平均数量。在一个四处理器系统中，有四个处理器队列，如果平均而言，四个CPU每个都正在为一个任务提供服务，而它们的队列中没有任务在等待，那么负载平均数将为4.0。没有问题。另一方面，在单处理器系统上的负载平均数为4.0会更让人担心。这意味着平均而言，独立的处理器正在为一个任务提供服务，而其他三个任务在等待它们的队列中。

负载平均值从未归一化。没有任何工具会将四处理器四任务的情况报告为负载平均值为1.0。如果平均有四个总任务在运行或等待CPU，无论有多少CPU，负载平均值将始终为4.0。

因此，在您开始探索指标之前，您首先需要知道您的服务器有多少个CPU。

你有多少个CPU？

你已经知道你有一个双核vServer，但是你可以使用带有–all选项的nproc命令来显示任何服务器上的处理器数量。如果没有–all标志，nproc将显示当前进程可用的处理单元数量，如果有任何处理器正在使用，则该数量将小于总处理器数。

1. nproc –all

2

在大多数现代Linux发行版上，您也可以使用lscpu命令，该命令不仅显示处理器的数量，还显示架构、型号名称、速度等等。

1. lscpu

Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 2 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 63 Model name: Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz Stepping: 2 CPU MHz: 1797.917 BogoMIPS: 3595.83 Virtualization: VT-x Hypervisor vendor: KVM Virtualization type: full L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 30720K NUMA node0 CPU(s): 0,1 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm vnmi ept fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat

CPU利用率和负载均衡的最佳值是多少？

服务器的最佳 CPU 利用率取决于其角色。有些服务器旨在充分利用 CPU，而其他服务器则不需要。进行统计分析或加密工作的应用程序或批处理作业可能会持续耗用 CPU 运算能力，接近或达到满负荷，而网页服务器通常不应该如此。如果您的网页服务器的 CPU 利用率达到了最大值，请不要盲目升级到更多或更快的 CPU 的服务器。相反，您应该检查是否存在恶意软件或其他不受控制的进程（无论是否合法），它们可能正在消耗 CPU 循环。

尽管您从未期望任何服务器的持续 CPU 利用率达到100%（标准化），但对于计算密集型应用程序而言，保持在接近100% 的使用率是合适的。如果不是这样，您可能拥有比您所需更多的 CPU 功率，也许可以通过降级服务器（或使用更少的服务器）来节省费用。

如果负载平均值低于或等于CPU数量，那么最佳负载平均值就是这个数值。只要双处理器系统的负载平均值保持低于2.0，你可以确信CPU时间很少发生争用（尽管队列可能会在短时间内膨胀）。

使用uptime来检查负载平均值。

uptime 命令是一个快速检查平均负载的方法。它非常有帮助，因为它轻量且运行迅速，甚至在系统因高负载而在命令行缓慢响应时也能迅速运行。

以下是服务器运行时间的命令输出：

• the system time
• how long the server has been running
• how many users are currently logged in
• the load average for the past one, five, and fifteen minutes

1. uptime

14:08:15 up 22:54, 2 users, load average: 2.00, 1.37, 0.63

在这个例子中，命令是在下午2点08分运行在一个已经运行了近23个小时的服务器上。有两个用户已经登录。第一个平均负载值为2.00，表示一分钟内的平均负载。由于这个服务器有两个CPU，负载平均值2.00意味着在uptime运行前一分钟内，平均有两个进程在使用CPU，没有进程在等待。五分钟的平均负载表示在那个时间间隔内，大约有60%的时间是有空闲处理器的。15分钟的值表示有更多的可用CPU时间。这三个数值共同显示了过去15分钟内对CPU需求的增加。

这个工具提供了一个有用的负载平均概览，但要获取更详细的信息，我们将转向top。

使用top工具检查CPU利用率

与uptime类似，top命令在Linux和Unix系统中都可用。但除了显示与uptime相同的平均负载，top还提供了总体系统和单个进程的CPU利用率、内存使用等数据。相比之下，uptime只运行一次然后退出，而top是交互式的。它展示了系统资源使用的仪表盘，并且保持在前台刷新，每隔几秒钟更新一次，直到按下q退出。

在运行top之前，给你的vServer一些任务来处理。运行以下命令对CPU造成一些负荷。

1. stress -c 2

现在打开另一个终端到您的vServer并运行top命令。

1. top

这将弹出一个交互式屏幕，显示资源利用概要以及所有系统进程的表格。让我们首先看一下顶部的概要信息。

页首块

以下是排名前五的第一行：

这里是排行榜上的前五名的第一行。

top – 22:05:28 up 1:02, 3 users, load average: 2.26, 2.27, 2.19 Tasks: 109 total, 3 running, 106 sleeping, 0 stopped, 0 zombie %Cpu(s): 99.8 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.2 st MiB Mem : 1975.7 total, 1134.7 free, 216.4 used, 624.7 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 1612.0 avail Mem

第一行和uptime的输出几乎完全相同。与uptime一样，显示了一分钟、五分钟和十五分钟的平均负载。这行和uptime的输出之间唯一的区别是开头显示了命令名称top，并且每次top刷新数据时时间会更新。

第二行总结了所有系统任务的状态：进程的总数量，其后是处于运行状态、睡眠状态、停止状态或僵尸状态的进程数量。

第三行告诉你有关CPU的利用率。这些数据是归一化的，并以百分比（不带%符号）显示，因此该行上的所有值应该加起来等于100%，无论CPU的数量如何。由于您在运行top命令之前使用了-c（CPU）选项启动了压力命令，所以第一个数值——us，或用户进程，应该接近100%。

第四行和第五行分别告诉你关于内存和交换空间使用情况。这个指南没有详细探讨内存和交换空间的使用情况，但当你需要的时候，它就在那里。

这个标题块后面跟着一张包含每个个体进程信息的表格，我们马上会看一下。

在下面的示例标题块中，一分钟负载平均值超过处理器数量0.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: time running un-niced user processes
  This category refers to user processes that were started with no explicit scheduling priority.
  Linux systems use the nice command to set a process’s scheduling priority, so “un-niced” means that nice wasn’t used to change the default value. The user and nice values account for all the user processes. High CPU use in this category may indicate a runaway process, and you can use the output in the process table to identify any culprits.
• sy, system: time running kernel processes
  Most applications have both user and kernel components. When the Linux kernel is doing something like making system calls, checking permissions, or interacting with devices on behalf of an application, the kernel’s use of the CPU is displayed here. When a process is doing its own work, it will appear in either the user figure described above or, if its priority was explicitly set using the nice command, in the nice figure that follows.
• ni, nice: time running niced user processes
  Like user, nice refers to CPU time that does not involve the kernel. But with nice, the scheduling priority for these tasks was set explicitly. The niceness (priority) of a process is indicated in the fourth column in the process table under the header NI. Processes with a niceness value between 1 and 20 that consume a lot of CPU time are generally not a problem because tasks with normal or higher priority will be able to get processing power when they need it. But if tasks with elevated niceness, between -1 and -20, are taking a disproportionate amount of CPU time, they can easily affect the responsiveness of the system and warrant further investigation. Note that many processes that run with the highest scheduling priority, -19 or -20 depending on the system, are spawned by the kernel to do important tasks that affect system stability. If you’re not sure about the processes you see, it’s prudent to investigate them rather than killing them.
• id, idle: time spent in the kernel idle handler
  This figure indicates the percentage of time that the CPU was both available and idle. A system is generally in good working order with respect to CPU when the user, nice, and idle figures combined are near 100%.
• wa, IO-wait: time waiting for I/O completion
  The IO-wait figure shows how much time a processor has spent waiting for I/O operations to complete. Read/write operations for network resources like NFS and LDAP will count in IO-wait as well. As with idle time, spikes here are normal, but any kind of frequent or sustained time in this state suggests an inefficient task, a slow device or network, or a potential hard disk problem.
• hi, hardware interrupts: time spent servicing hardware interrupts
  This is the time spent on physical interrupts sent to the CPU from peripheral devices like disks and hardware network interfaces. When the hardware interrupt value is high, you may have a peripheral device that has gone bad.
• si, software interrupts: time spent servicing software interrupts
  Software interrupts are sent by processes rather than physical devices. Unlike hardware interrupts that occur at the CPU level, software interrupts occur at the kernel level. When the software interrupt value is high, investigate the specific processes that are using the CPU.
• st, steal: time stolen from this vm by the hypervisor
  The steal value shows how long a virtual CPU spends waiting for a physical CPU while the hypervisor is servicing itself or a different virtual CPU. Essentially, the amount of CPU use in this field indicates how much processing power your VM is ready to use, but which is not available to your application because it is being used by the physical host or another virtual machine. Generally, seeing a steal value of up to 10% for brief periods of time is not a cause for concern. Larger amounts of steal for longer periods of time may indicate that the physical server has more demand for CPU than it can support.

现在，我们已经查看了top命令标题中提供的CPU使用摘要，接下来我们将看一下出现在摘要下方的进程表，注意到CPU特定的列。

进程表

下面是一个示例top输出中进程表的前六行。

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9966 sammy 20 0 9528 96 0 R 99.7 0.0 0:40.53 stress 9967 sammy 20 0 9528 96 0 R 99.3 0.0 0:40.38 stress 7 root 20 0 0 0 0 S 0.3 0.0 0:01.86 rcu_sched 1431 root 10 -10 7772 4556 2448 S 0.3 0.1 0:22.45 iscsid 9968 root 20 0 42556 3604 3012 R 0.3 0.1 0:00.08 top 9977 root 20 0 96080 6556 5668 S 0.3 0.2 0:00.01 sshd . . .

服务器上的所有进程，无论处于任何状态，都在标题下方列出。默认情况下，进程表按照“%CPU”列进行排序，因此您将在顶部看到消耗最多CPU时间的进程。

%CPU 值以百分比形式呈现，但与标题中的 CPU 利用率数据不同，进程表中的数据没有被归一化。因此，在这个双核系统上，当两个处理器都完全被利用时，进程表中所有值的总和应该达到 200%。

你可以使用不同的按键（包括交互方式）来实时控制top命令和服务器的进程。

• SHIFT-M to sort processes by memory usage.
• SHIFT-P to sort processes by CPU usage.
• k, followed by a process ID (PID) and a signal, to kill an unruly process. After entering a PID, try a signal of 15 (SIGTERM) first, which is the default. Do not use 9 (SIGKILL) carelessly.
• r, followed by a process ID, to renice (reprioritize) a process.
• c to toggle the command descriptions between a short description (the default) and the full command string.
• d to change the refresh interval for the figures in top.

还有更多。阅读顶部的 man 页（man top）以获取更多详细信息。

到目前为止，你已经学习了两个常用于查看负载平均值和CPU利用率的Linux命令。尽管这些工具很有用，但它们只能提供一个短暂时间内服务器状态的一瞥。你不能一直坐在那里观察top命令。为了更好地了解服务器资源使用的长期模式，你需要某种监控解决方案。在下一节中，你将简要介绍Silicon Cloud vServers免费提供的监控工具。

使用Silicon Cloud监控系统随时间跟踪度量指标。

在控制面板中点击vServer名称时，默认显示带宽、CPU和磁盘I/O图表。你无需安装Silicon Cloud代理即可获得这三个图表。

这些图表可以帮助你可视化每种资源在过去的1小时、6小时、24小时、7天和14天内的使用情况。CPU图表提供了CPU利用率信息。深蓝色线条表示用户进程的CPU使用情况。浅蓝色表示系统进程的CPU使用情况。图表上的数值及其详细信息被标准化，使得总容量始终为100%，无论虚拟核心数量为多少。

通过图表可以看到您是否正在经历间歇性或持续性的用量变化，并有助于发现服务器CPU使用模式的变化。

除了默认的图表外，您可以在vServer上安装Silicon Cloud代理程序，以收集和显示额外的数据，如负载平均值、磁盘使用率和内存使用率。代理程序还允许您为系统设置警报策略。如何安装和使用Silicon Cloud监控代理程序可以帮助您进行设置。

安装了代理之后，您可以设置警报策略，以便通知您有关资源使用情况的信息。您选择的阈值将取决于服务器的典型工作负载。

示例提醒

监控变化：CPU使用率超过1%。

如果你主要使用vServer来集成和浸泡测试代码，你可以设置一个警报，略高于历史模式，以便检测到推送到服务器的新代码是否增加了CPU使用率。对于上面的图表，其中CPU从不达到1%，一个使用率为1%的CPU使用阈值持续5分钟可能提供有关基于代码的更改影响CPU使用情况的早期警告。

在Silicon Cloud控制面板中，在左侧的”管理”菜单下，点击”监控”。在默认高亮显示的”资源警报”选项卡下，点击”创建资源警报”。填写表格并点击”创建资源警报”。

在大多数系统上，这个阈值很可能完全不合适，但是如果你能通过查看过去几周的CPU图表来确定正常工作负载期间的典型CPU利用率，你可以创建一个略高于正常利用率的阈值，并在新代码或新服务对CPU利用率产生影响时早早得到警报。

紧急情况监控：CPU利用率超过90%

你可能也想设置一个远高于平均水平的阈值，一个你认为是关键的、值得及时调查的阈值。例如，如果一个服务器的持续CPU使用率在五分钟的时间间隔内一直保持在50%，但突然间剧增到90%，那你可能希望立即登录进行调查。再次强调，这些阈值是根据系统的工作负载而定的。

结论是

在这篇文章中，我们探讨了uptime和top这两个常用的Linux实用工具，它们可以提供关于Linux系统的CPU利用率和负载平均值的信息，以及如何使用Silicon Cloud监控来查看滴答上历史CPU利用率并在变化和紧急情况下向您发出警报。要了解更多关于Silicon Cloud监控的信息，请阅读关于度量、监控和警报的介绍。您还可以阅读我们的文档。

想知道您的工作负载所需的vServer种类是什么，可以阅读《选择适合的vServer计划》获取帮助。