排查 Azure Windows 虚拟机上的 CPU 使用率过高问题

摘要

性能问题发生在不同的操作系统或应用程序中,每个问题都需要一种独特的方法来进行故障排除。 其中大多数问题都与 CPU、内存、网络和输入/输出 (I/O) 作为出现问题的关键位置有关。 每个区域都会产生不同的症状 (有时同时) ,需要不同的诊断和解决方案。

本文讨论运行 Windows 操作系统) Azure 虚拟机 (VM 上出现的 CPU 使用率过高问题。

Azure Windows VM 上的 CPU 使用率过高问题

除了 I/O 和网络延迟问题外,CPU 和内存故障排除需要与本地服务器相同的工具和步骤。 Microsoft 通常支持的工具之一是 PerfInsights (适用于 Windows 和 Linux) 。 PerfInsights 可以在用户友好的报告中提供 Azure VM 最佳做法诊断。 PerfInsights 也是一个包装器工具,它可以帮助收集 Perfmon、Xperf 和 Netmon 数据,具体取决于工具中选择的标志。

用于本地服务器的大多数现有性能故障排除工具(例如 Perfmon 或 Procmon)可在 Azure Windows VM 上运行。 但是,PerfInsights 专为 Azure VM 显式设计,旨在提供更多见解,包括 Azure 最佳做法、SQL 最佳做法、高分辨率 I/O 延迟图、CPU 和内存选项卡等。

无论它是作为 User-Mode 还是内核模式运行,活动进程的任何线程都需要 CPU 周期来运行生成的代码。 许多问题与工作负荷直接相关。 服务器上存在的工作负荷类型会驱动资源消耗,包括 CPU。

常见因素

在 CPU 使用率高的情况下,以下因素很常见:

  • 最近的代码更改或部署,主要适用于 Internet Information Services (IIS) 、Microsoft SharePoint、Microsoft SQL Server 或第三方应用程序等应用。

  • 与 OS 级更新或应用程序级累积更新和修复相关的最新更新。

  • 查询更改或过时的索引。 SQL Server和 Oracle 数据层应用程序还将查询计划优化作为另一个因素。 数据更改或缺少适当的索引可能会导致多个查询变得更加计算密集型。

  • 特定于 Azure VM。 某些进程(如 RDAgent)和特定于扩展的进程(如监视代理、MMA 代理或安全客户端)可能会导致 CPU 使用率过高。 必须从配置或已知问题的角度查看这些进程。

排查问题

本文重点介绍如何隔离有问题的流程。 进一步分析将特定于导致高 CPU 消耗的进程。

例如,如果进程SQL Server (sqlservr.exe) ,则后续步骤是分析哪个查询在特定时间段内使用了最多的 CPU 周期。

确定问题范围

下面是排查问题时要问的几个问题:

  • 此问题是否有模式? 例如,高 CPU 问题是否发生在每天、每周或每月的特定时间? 如果是这样,是否可以将此问题关联到作业、报表或用户登录名?

  • 在最近的代码更改后,高 CPU 问题是否开始出现? 你是在 Windows 还是应用程序中应用更新?

  • 高 CPU 问题是否在工作负荷更改后开始,例如用户数增加、数据流入量增加或报告数量增加?

  • 对于 Azure,高 CPU 问题是否在以下任何条件下开始?

    • 最近重新部署或重启后
    • SKU 或 VM 类型更改时
    • 添加新扩展时
    • 在进行负载均衡器更改后

Azure 注意事项

了解工作负载。 选择 VM 时,在查看整体每月托管成本时,可能会低估虚拟 CPU (vCPU) 计数。 如果工作负荷是计算密集型的,则选择具有一个或两个 vCPU 的较小 VM SKU 可能会导致工作负荷问题。 测试工作负载的不同配置,以确定所需的最佳计算功能。

某些 VM 系列(例如 B (突发模式) 系列)建议用于质量保证 (QA) 和测试。 在生产环境中使用这些系列会限制 CPU 额度耗尽后的计算能力。

对于SQL Server、Oracle、RDS (远程桌面服务) 、Azure 虚拟桌面、IIS 或 SharePoint 等已知应用程序,有一些 Azure 最佳做法文章包含针对这些工作负载的最低配置建议。

持续的高 CPU 问题

如果问题正在发生,则这是捕获进程跟踪以确定导致问题的原因的最佳机会。 可以使用已用于本地 Windows 服务器的现有工具来查找进程。 Azure VM 支持人员建议使用以下工具。

PerfInsights

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

运行 PerfInsights

PerfInsights 适用于 WindowsLinux OS。 对于 Windows,以下是选项。

通过 Azure 门户 运行和分析报表

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

Azure 门户选项 1

浏览 VM 边栏选项卡,然后选择“性能诊断”选项。 系统会要求你安装选项, (在所选的 VM 上使用扩展) 。

“性能诊断”选项中的“安装性能诊断”按钮的屏幕截图。

Azure 门户选项 2

浏览到 VM 边栏选项卡中的 “诊断和解决问题 ”,并查找 VM 性能问题

“诊断并解决问题”选项中 VM 性能问题的屏幕截图。

如果选择“ 故障排除”,将加载 PerfInsights 安装屏幕。

如果选择“ 安装”,则安装会提供不同的收集选项。

“性能诊断”选项中“性能分析”设置的屏幕截图。

屏幕截图中的编号选项与以下注释相关:

  1. 对于“ 高 CPU”选项,请选择“ 性能分析 ”或“ 高级”。

  2. 在此处添加症状时,它们将添加到报表中,这有助于与 Azure 支持人员共享信息。

  3. 选择数据收集的持续时间。 对于“高 CPU”选项,请选择至少 15 分钟或更长。 在Azure 门户模式下,最多可以收集 15 分钟的数据。 对于较长的收集期,必须在 VM 中将程序作为可执行文件运行。

  4. 如果 Azure 支持部门要求你收集此数据,可以在此处添加票证编号。 此字段是可选的。

  5. 选择此字段以接受最终用户许可协议 (EULA) 。

  6. 如果打算将此报告提供给 Azure 支持团队,请选中此字段来帮助解决此问题。

报表存储在订阅下的其中一个存储帐户上。 稍后可查看和下载。

从 VM 中运行 PerfInsights

如果打算运行更长的 PerfInsights 持续时间,则可以使用此方法。 PerfInsights 一文详细介绍了将 PerfInsights 作为可执行文件运行所需的不同命令和标志。 为了高 CPU 使用率,需要以下模式之一:

  • 高级方案

    • PerfInsights /run advanced xp /d 300 /AcceptDisclaimerAndShareDiagnostics
  • VM 慢 (性能) 方案

    • PerfInsights /run vmslow /d 300 /AcceptDisclaimerAndShareDiagnostics /sa <StorageAccountName> /sk <StorageAccountKey>

命令输出将位于保存 PerfInsights 可执行文件的同一文件夹中。

在报表中查找的内容

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

运行Azure 门户

高影响性能诊断的屏幕截图。

“性能诊断报表”页中“下载报表”按钮的屏幕截图。

从 VM 中运行

文件夹结构应类似于下图:

文件夹结构中的输出文件夹和 PerfInsight 报表 HTML 文件的屏幕截图。

文件夹结构中GeneralCounters_000001.blg 和 System.evtx 的屏幕截图。

  1. 任何其他集合(如 Perfmon、Xperf、Netmon、SMB 日志、事件日志等)都可以在“输出”文件夹中找到。

  2. 实际报告以及分析和建议。

  3. 对于性能 (VMlow) 和 Advanced,报告会收集 PerfInsights 运行持续时间的 perfmon 信息。

  4. 事件日志显示有用的系统级或进程崩溃详细信息的快速视图。

从何处开始?

打开 PerfInsights 报表。 “ 发现 ”选项卡记录资源消耗量的任何离群值。 如果存在高 CPU 使用率的实例,“ 发现 ”选项卡会将其分类为“高影响”或“中等影响”。

“PerfInsights 报告”页 CPU 部分中的“发现结果”选项卡的屏幕截图。在此示例中,“影响级别”为“中等”。

与上一示例类似,PerfInsights 运行了 30 分钟。 在该时间的一半时间里,突出显示的进程在较高端耗尽了 CPU。 如果相同的进程在整个收集过程中一直在运行,则影响级别将更改为 HIGH

如果展开“ 发现” 事件,将看到几个关键详细信息。 选项卡按 平均 CPU 消耗量按降序列出进程,并显示进程是否与系统、Microsoft 拥有的应用 (SQL、IIS) 或第三方进程相关。

更多详细信息

CPU 下有一个专用子表,可用于按核心或按进程进行详细模式分析。

CPU 使用者排名靠前 ”选项卡有两个单独的相关部分,可在此处查看每个处理器的统计信息。 应用程序设计通常 Single-Threaded 或固定到单个处理器。 在此方案中,一个或几个核心以 100% 的速度运行,而其他核心以预期级别运行。 这些方案更为复杂,因为服务器上的平均 CPU 似乎按预期运行,但固定在使用率较高的内核上的进程将比预期慢。

“PerfInsights 报告”页的 CPU 部分中的“CPU 使用者排名靠前”选项卡的屏幕截图,其中显示了“性能诊断分析周期”和“CPU 使用率过高时段”。

第二部分 (同样重要的) 是 排名靠前的长时间运行的 CPU 使用者。 本部分显示进程详细信息及其 CPU 使用模式。 列表按在顶部具有较高的平均 CPU 使用者进行排序。

“最长时间运行的 CPU 使用者”部分的屏幕截图。

这两个选项卡足以设置后续故障排除步骤的路径。 根据导致高 CPU 条件的进程,必须解决之前提出的问题。 SQL Server (sqlservr.exe) 或 IIS (w3wp.exe) 等进程需要对导致这种情况的查询或代码更改进行特定的向下钻取。 对于 WMI 或 Lsass.exe 等系统进程,必须遵循不同的路径。

对于与 Azure VM 相关的过程(如 RDAgent、OMS 和监视扩展可执行文件),可能需要通过获取 Azure 支持团队的帮助来修复新版本或版本。

Perfmon

Perfmon 是用于排查 Windows Server 上资源问题的最早工具之一。 它不会提供包含建议或发现结果的明确报告。 相反,它要求用户浏览收集的数据,并在不同的计数器类别下使用特定筛选器。

PerfInsights 将 Perfmon 收集为 VMSlow 和高级方案的额外日志。 但是,Perfmon 可以独立收集,并具有以下附加优势:

  • 可以远程收集它。

  • 可以通过 任务计划它。

  • 可以使用滚动更新功能在较长的持续时间内或在连续模式下收集它。

请考虑 PerfInsights 中显示的相同示例,了解 Perfmon 如何显示此数据。 所需的计数器类别如下:

  • 处理器信息 > %处理器时间 > _Total

  • 进程 > %ProcessorTime > 所有实例

从何处开始?

Perfmon 的输出文件名具有 .blg 扩展名。 可以单独收集这些文件,也可以使用 PerfInsights 收集这些文件。 对于此讨论,你将使用 PerfInsights 数据中包含的、根据上一个示例收集的 Perfmon .blg

Perfmon 中没有可用的默认用户就绪报表。 有不同的视图可以更改图形类型,但过程过滤 (或识别罪魁祸首过程所需的工作) 是手动的。

注意

PAL 工具可以使用.blg文件并生成详细报告。

若要开始,请选择“ 添加计数器” 类别。

  1. “可用计数器”下,选择“处理器信息类别”中的“%ProcessorTime”计数器。

  2. 选择 “_Total”,这会提供所有组合核心的统计信息。

  3. 选择“添加”。 窗口在“添加的计数器”下显示 %ProcessorTime

性能监视器中“添加计数器”对话框的屏幕截图。

加载计数器后,你将在集合时间范围内看到折线趋势图。 可以选择或清除计数器。 到目前为止,你只添加了一个计数器。

收集时间范围内折线趋势图的屏幕截图。

每个计数器都具有 AverageMinimumMaximum 值。 关注 “平均值 ”和“ 最大值 ”,因为平均值可能因数据收集的持续时间而异。 如果看到高 CPU 活动 10 分钟,而整个集合为 40 分钟,则平均值将低得多。

上一个趋势图显示 ,总处理器 在大约 15 分钟内接近 80%。

确定流程

我们已确定服务器在指定时间内的 CPU 使用率较高,但尚未确定驱动程序。 与使用 PerfInsights 不同,在这种情况下,必须手动搜索罪魁祸首进程。

对于此任务,必须清除或删除之前添加的 %ProcessorTime 计数器,然后添加新类别:

  • 进程 > %ProcessorTime > 所有实例

此类别将为当时运行的所有进程加载计数器。

添加新类别的步骤的屏幕截图。

在典型的生产计算机上,可以运行数百个 或 进程。 因此,可能需要一段时间才能清除每个似乎具有低或平趋势图的计数器。

若要加速此过程,请使用直方图视图,并将视图类型从“线条”更改为“直方图”,这将为你提供条形图。 你会发现,选择在收集期间遇到高 CPU 使用率的进程会更容易。

因为 Total 始终会有一个条形图,所以请关注显示高耗尽率的条形图。 可以删除其他条形图以清理视图。 现在,切换回 “线条” 视图。

性能监视器中的“直方图视图”按钮的屏幕截图以及一个示例图表,其中包含显示高耗尽率的 2 个条形图。

现在更容易捕获罪魁祸首过程。 默认情况下, MaxMin 值是服务器上核心数或进程线程数的倍数。

折线趋势图的屏幕截图,其中清楚地显示了罪魁祸首过程。

可用工具列表不会以 Perfmon 的 PerfInsights 结尾。 你可以访问其他工具,例如 ProcessMonitor (ProcMon) 或 Xperf。 有许多第三方工具可供根据需要使用。

Azure 监视工具

Azure VM 具有可靠的指标,其中包括 CPU、网络 I/O 和 I/O 字节等基本信息。 对于高级指标(如 Azure Monitor),只需进行一些选择即可配置和使用指定的存储帐户。

基本 (默认) 计数器

Azure Monitor 的“指标”页的屏幕截图。在此示例中,选择了“聚合”设置中的“CPU 百分比”选项。

启用 Azure Monitor

启用 Azure Monitor 指标后,软件会在 VM 上安装扩展,然后开始收集精细指标,其中包括 Perfmon 计数器。

“诊断设置”页的“概述”选项卡中“诊断存储帐户”字段的屏幕截图。

“基本”计数器类别设置为默认值。 但是,还可以设置 自定义 集合。

“诊断设置”页的“性能计数器”选项卡中“基本类别”选项的屏幕截图。

启用设置后,可以在“指标”部分查看这些来宾计数器。 还可以设置 警报 (包括电子邮件) (如果指标达到特定阈值)。

“指标”页中“指标命名空间”字段和“新建警报规则”按钮的屏幕截图。

有关如何使用 Azure Monitor 管理 Azure VM 的详细信息,请参阅 使用 Azure Monitor 监视 Azure 虚拟机

反应式故障排除

如果问题已发生,则必须首先发现导致 CPU 使用率过高的问题的原因。 反应立场可能很棘手。 数据收集模式将不太有用,因为问题已经发生。

如果此问题是一次性出现,则可能难以确定是哪个应用导致了此问题。 如果 Azure VM 已配置为使用 OMS 或其他诊断跟踪,你仍可以深入了解导致该问题的原因。

如果要处理重复模式,请在问题可能接下来发生期间收集数据。

PerfInsights 尚没有 计划的运行 功能。 但是,可以通过命令行运行和计划 Perfmon。

Logman 命令

Logman Create Counter 命令用于通过命令行运行 Perfmon 集合、通过任务管理器对其进行计划或远程运行。

示例 (包括远程收集模式)

Logman create counter LOGNAME -u DOMAIN\USERNAME * -f bincirc -v mmddhhmm -max 300 -c "\\SERVERNAME\LogicalDisk(*)\*" "\\SERVERNAME\Memory\*" "\\SERVERNAME\Network Interface(*)\*" "\\SERVERNAME\Paging File(*)\*" "\\SERVERNAME\PhysicalDisk(*)\*" "\\SERVERNAME\Process(*)\*" "\\SERVERNAME\Redirector\*" "\\SERVERNAME\Server\*" "\\SERVERNAME\System\*" "\\SERVERNAME\Terminal Services\*" "\\SERVERNAME\Processor(*)\*" "\\SERVERNAME\Cache\*" -si 00:01:00

还可以从同一 VNET 中的对等 Azure VM 计算机启动 Logman.exe。

若要详细了解这些参数,请参阅 logman 创建计数器

在出现问题时收集 Perfmon 数据后,分析数据的剩余步骤与前面讨论的步骤相同。

总结

对于任何性能问题,了解工作负载是解决问题的关键。 必须通过将重点放在生产工作负荷来评估不同 VM SKU 和不同磁盘存储选项上的选项。 在不同 VM 上测试解决方案的过程可以帮助你做出最佳决策。

由于用户操作和数据量各不相同,因此始终在 VM 的计算、网络和 I/O 功能中保留一个缓冲区。 现在,工作负载的任何突然变化都不会产生太大的影响。

如果预计工作负载会很快增加,请迁移到具有更多计算能力的更高 SKU。 如果工作负荷需要大量计算,请明智地选择 VM SKU。

联系我们寻求帮助

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