适用于：✔️ Linux VM

当不同操作系统和应用程序中出现性能问题时，每个情况都需要唯一的方法进行故障排除。 CPU、内存、网络和输入/输出（I/O）是可能出现问题的关键领域。 其中每个区域都显示了不同的症状（有时同时出现），需要不同的诊断和解决方案。

性能问题可能是应用程序或设置配置不当造成的。 例如，具有未正确配置的缓存层的 Web 应用程序。 这种情况会触发更多的请求流回源服务器，而不是从缓存中提供服务。

在另一个示例中，MySQL 或 MariaDB 数据库的重做日志位于操作系统（OS）磁盘或不符合数据库要求的磁盘上。 在此方案中，由于资源的竞争和更高的响应时间（延迟），每秒事务数（TPS）可能会减少。

如果完全了解此问题，可以更好地确定堆栈上的位置（CPU、内存、网络、I/O）。 若要排查性能问题，必须建立一个 基线 ，用于在进行更改后比较指标，并评估整体性能是否有所改善。

排查虚拟机（VM）性能问题与解决物理系统上的性能问题不同。 这是关于确定哪个资源或组件导致系统中的 瓶颈 。

请务必了解瓶颈始终存在。 性能故障排除完全是了解瓶颈的发生位置以及如何将其移动到不太有问题的资源。

本指南可帮助你发现和解决 Linux 环境中的 Azure 虚拟机中的性能问题。

可以获取确认或拒绝资源约束是否存在的性能指针。

根据调查的资源，许多工具可以帮助你获取与该资源相关的数据。 下表包含主要资源的示例。

后续部分将讨论可用于查找主要资源的指针和工具。

使用或不使用特定百分比的 CPU。 同样，进程要么花费在 CPU（如 80% 使用率）中，要么不（例如 80% 空闲）。 确认 CPU 使用率的主要工具是 。

默认情况下，该工具 以交互模式运行。 它会每隔一秒刷新一次，并按 CPU 使用率排序显示进程：

现在，查看该输出中的 进程行：

可以看到该 进程消耗了 99.7% 的 CPU。

另一个有用的引用是负载平均值。 负载平均值以 1 分钟、5 分钟和 15 分钟的间隔显示平均系统负载。 该值指示系统的负载级别。 解释此值取决于可用的 CPU 数。 例如，如果一个 CPU 系统上的负载平均值为 2，则系统会加载系统，以便进程开始排队。 如果四 CPU 系统上的负载平均为 2，则总 CPU 使用率约为 50%。

在前面的示例中，负载平均值为 1.04。 这是一个双 CPU 系统，这意味着 CPU 使用率约为 50%。 如果注意到 48.5% 的空闲 CPU 值，则可以验证此结果。 （在命令输出中 ，空闲的 CPU 值显示在标签之前 。

使用负载平均值快速概述系统的性能。

运行命令以获取负载平均值。

调查 I/O 性能问题时，以下术语可帮助你了解问题发生的位置。

输入输出操作每秒 （IOPS）是一个按特定时间（在本例中，秒）测量的输入和输出（I/O）操作数的函数。 I/O 操作可以是读取或写入。 删除或放弃也可以算作针对存储系统的操作。 每个操作都有一个与 I/O 大小相等的分配单元。

I/O 大小通常在应用程序级别定义为每个事务写入或读取的数据量。 常用的 I/O 大小为 4K。 但是，包含更多线程的较小 I/O 大小会生成更高的 IOPS 值。 由于每个事务的完成速度相对较快（由于其大小较小），因此较小的 I/O 允许在同一时间内完成更多的事务。

相反，假设线程数相同，但使用更大的 I/O。 IOPS 会减少，因为每个事务需要更长的时间才能完成。 但是，吞吐量会增加。

请考虑以下示例：

1,000 IOPS 表示每秒完成一千个操作。 每个操作大约需要一毫秒。 （一秒内有 1,000 毫秒。从理论上讲，每个事务的完成时间大约为 1 毫秒，或大约 1 毫秒的延迟。

通过了解 IOSize 值和 IOPS，可以通过将 IOSize 乘以 IOPS 来计算吞吐量。

例如：

• 1,000 IOPS，4K IOSize = 4,000 KB/秒，或 4 MB/秒（精确 3.9 MB/秒）

• 1,000 IOPS（以 1M IOSize 表示 1,000 MB/秒）或 1 GB/秒（精确为 976 MB/秒）

可以按如下所示编写更易公式的版本：

与 IOPS 不同，吞吐量是一段时间内数据的函数。 这意味着，每秒都会写入或读取一定量的数据。 此速度以<数据/<>量时间>或每秒兆字节（MB/秒）来测量。

如果知道吞吐量和 IOSize 值，可以通过将吞吐量除以 IOSize 来计算 IOPS。 应将单位规范化为最小内涵。 例如，如果 IOSize 以 KB 为单位定义，则应转换吞吐量。

公式格式按如下方式编写：

若要将此公式放入上下文中，请考虑在 IOSize 为 4K 的吞吐量为 10 MB/秒。 在公式中输入值时，结果为 10,240/4=2,560 IOPS。

延迟是测量每个操作完成所花费的平均时间。 IOPS 和延迟相关，因为这两个概念都是时间函数。 例如，在 100 IOPS 处，每个操作大约需要 10 毫秒才能完成。 但是，在较低的 IOPS 下，可以更快地提取相同的数据量。 延迟也称为搜寻时间。

作为 sysstat 包的一部分， 该工具提供有关磁盘性能和使用情况指标的见解。 可以帮助识别与磁盘子系统相关的瓶颈。

可以在简单命令中运行 。 基本语法如下：

这些参数决定了提供哪些信息 。 如果没有任何命令参数， 则显示基本详细信息：

默认情况下， 显示所有现有块设备的数据，尽管为每个设备提供了最少的数据。 参数可通过提供扩展数据（例如吞吐量、IOPS、队列大小和延迟）来帮助识别问题。

通过指定触发器运行 ：

若要进一步扩展 结果，请使用以下参数。

命令中的数字 指示 每秒刷新一次。 若要停止刷新，请选择 Ctrl+C。

如果包含额外的参数，输出将类似于以下文本：

下表显示了输出中的 主列。

提供 的数据是信息性的，但某些列中存在某些数据并不意味着存在问题。 应始终捕获和分析来自 的数据，以获取可能的瓶颈。 高延迟可能表示磁盘达到饱和点。

网络可能会遇到两个主要瓶颈：低带宽和高延迟。

可用于 实时捕获带宽详细信息。 但是， 在所有分发版中都不可用。 广泛使用 的工具是查看实时接口流量的另一个选项。

可以使用 Internet 控制消息协议中的简单 命令来确定两个不同的系统中的网络延迟（ICMP）：

若要停止 ping 活动，请选择 Ctrl+C。

可以使用诸如以下 工具验证网络带宽。 该工具 适用于通过指定 服务器上的标志来启动应用程序的服务器/客户端模型。 然后，客户端通过指定服务器的 IP 地址或完全限定的域名（FQDN）与 标志连接到服务器。 以下代码片段演示如何 在服务器和客户端上使用该工具。

• Server

• 客户端

下表显示了客户端的一些常见 参数。

内存是用于检查的另一种故障排除资源，因为应用程序可能或可能不会使用部分内存。 可以使用诸如和查看总体内存利用率的工具，并确定各种进程消耗的内存量：

在 Linux 系统中，通常可以看到 99% 的内存利用率。 在输出中 ，有一个名为的列 。 Linux 内核使用免费（未使用的）内存来缓存 I/O 请求，以提高响应时间。 此过程称为 页面缓存。 在内存压力（内存不足的情况下），内核返回用于页面缓存的内存，以便应用程序可以使用该内存。

在输出中，可用列指示可供进程使用多少内存。 此值通过添加 buff/cache 内存和可用内存量来计算。

可以将命令配置为 按内存利用率对进程进行排序。 默认情况下， 按 CPU 百分比进行排序 。。 若要按内存利用率进行排序 ，请在运行时选择 Shift+M。 以下文本显示命令的 输出：

该 列指示 驻留内存。 这表示实际进程使用情况。 该工具 提供与千字节（KB）类似的输出 。

如果应用程序遇到 内存泄漏，内存利用率可能会超过预期。 在内存泄漏方案中，应用程序无法释放不再使用的内存页。

下面是另一个命令，用于查看顶部内存消耗进程：

以下文本显示了命令的示例输出：

可以识别内存不足（OOM） 终止 事件的内存压力，如以下示例输出中所示：

使用 RAM（物理内存）和 SWAP（磁盘）后调用 OOM。

可以使用以前的指示器和了解当前配置来确定是否存在约束。 可将约束与现有配置进行比较。

下面是磁盘约束的示例：

D2s_v3 VM 能够 48 MB/秒的未缓存吞吐量。 对于此 VM，附加了能够 200 MB/秒的 P30 磁盘。 应用程序至少需要 100 MB/秒。

在此示例中，限制资源是整个 VM 的吞吐量。 应用程序的要求与磁盘或 VM 配置可以提供的内容指示约束资源。

如果应用程序需要 <measurement1<>资源>，并且资源的>当前配置<只能提供< measurement2>，则此要求可能是一个限制因素。

确定要成为当前配置中限制因素的资源后，确定资源如何更改，以及它如何影响工作负荷。 在某些情况下，由于节约成本措施，可能会限制资源，但应用程序仍能够处理瓶颈，而不会出现问题。

例如：

如果应用程序需要 128 GB（度量）RAM（资源），并且 RAM（资源）的当前配置只能提供 64 GB（度量），则此要求可能是一个限制因素。

现在，可以定义限制资源，并根据该资源执行操作。 相同的概念适用于其他资源。

如果这些限制资源预期为节省成本的措施，则应用程序应解决瓶颈问题。 但是，如果存在相同的节约成本措施，并且应用程序无法轻松处理资源不足，则此配置可能会导致问题。

设计性能不是为了解决问题，而是要了解下一个瓶颈的发生位置以及如何解决此问题。 瓶颈始终存在，只能移动到设计的不同位置。

例如，如果应用程序受到磁盘性能的限制，则可以增加磁盘大小以允许更多吞吐量。 但是，网络随后成为下一个瓶颈。 由于资源有限，因此没有理想的配置，因此必须定期解决问题。

通过在前面的步骤中获取数据，现在可以根据实际、可度量的数据进行更改。 还可以将这些更改与之前测量的基线进行比较，以验证是否存在明显差异。

请考虑以下示例：

在应用程序运行时获取基线时，确定系统在配置两个 CPU 时 CPU 使用率为 100%。 你观察到的负载平均值为 4。 这意味着系统正在排队请求。 对 8 CPU 系统的更改将 CPU 使用率降低到 25%，应用相同负载时，负载平均值减少到 2。

在此示例中，将获取的结果与更改的资源进行比较时，存在可度量的差异。 在更改之前，存在明确的资源约束。 但在更改后，有足够的资源来增加负载。

从本地设置迁移到云计算可能会受到多种性能差异的影响。

根据体系结构，本地设置可能会运行具有更高时钟速度和更大缓存的 CPU。 结果将减少处理时间和更高的每个周期指令（IPC）。 在处理迁移时，请务必了解 CPU 模型和指标之间的差异。 在这种情况下，CPU 计数之间的一对一关系可能不够。

例如：

在本地系统中，有四个 CPU 在 3.7 GHz 上运行，总共有 14.8 GHz 可用于处理。 如果使用由 2.1-GHz CPU 支持的 D4s_v3 VM 创建 CPU 计数中的等效项，则迁移的 VM 有 8.1 GHz 可供处理。 这表示性能下降约 44%。

Azure 中的磁盘性能由磁盘的类型和大小定义（超级磁盘除外，后者提供大小、IOPS 和吞吐量的灵活性）。 磁盘大小定义 IOPS 和吞吐量限制。

延迟是依赖于磁盘类型而不是磁盘大小的指标。 大多数本地存储解决方案都是具有 DRAM 缓存的磁盘阵列。 这种类型的缓存提供子毫秒（约 200 微秒）延迟和高读/写吞吐量（IOPS）。

下表显示了平均 Azure 延迟。

本地（通常小于毫秒）和高级 SSD（单位数毫秒）之间的延迟差将成为一个限制因素。 请注意存储产品/服务之间的延迟差异，并选择更符合应用程序要求的套餐。

大多数本地网络设置使用 10 Gbps 链接。 在 Azure 中，网络带宽直接由虚拟机（VM）的大小定义。 某些网络带宽可能超过 40 Gbps。 请确保选择具有足够带宽的大小，以满足应用程序需求。 在大多数情况下，限制因素是 VM 或磁盘的吞吐量限制，而不是网络。

选择具有足够 RAM 的 VM 大小，以便为当前配置的内容。

PerfInsights 是针对 VM 性能问题的Azure 支持建议的工具。 它旨在涵盖 CPU、内存和 I/O 的最佳做法和专用分析选项卡。 可以通过Azure 门户或 VM 内部运行 OnDemand，然后与Azure 支持团队共享数据。

PerfInsights 适用于 Windows 和 Linux OS。 验证 Linux 分发是否在 Linux 性能诊断支持的分发版列表中。

通过 Azure 门户 安装 PerfInsights 时，软件会在 VM 上安装扩展。 用户还可以直接转到 VM 边栏选项卡中的“扩展”，然后选择性能诊断选项，将 PerfInsights 安装为扩展。

Azure 门户选项 1

浏览 VM 边栏选项卡并选择 “性能诊断 ”选项。 系统要求你在为其选择该选项的 VM 上安装选项（使用扩展）。

Azure 门户选项 2

浏览到 VM 边栏选项卡中的“诊断和解决问题”选项卡，并查找 VM 性能问题下的“故障排除”链接。

在 PerfInsights 报表中查找的内容

运行 PerfInsights 报表后，内容的位置取决于报表是通过Azure 门户运行还是作为可执行文件运行。 对于任一选项，访问生成的日志文件夹，或者（如果在本地Azure 门户中）下载进行分析。

打开 PerfInsights 报表。 “ 查找 ”选项卡根据资源消耗记录任何离群值。 如果由于特定资源使用率而性能缓慢，则 “查找 ”选项卡会将每个发现分类为 “高 影响”或 “中等 影响”。

例如，在以下报告中，我们看到 检测到与存储相关的中等 影响结果，并看到相应的建议。 如果展开 “查找” 事件，则会看到几个关键详细信息。

有关 Linux OS 中的 PerfInsights 的详细信息，请参阅 如何在 Azure Microsoft中使用 PerfInsights Linux。

• 排查 Linux 或 Windows 上的 Azure 虚拟机性能问题

• Azure 虚拟机的性能诊断

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 你还可以将产品反馈提交到 Azure 反馈社区。