ACM通信

实践

有条不紊地思考绩效

由丹格雷格
ACM通信，2013年2月，第56卷第2期，第45-51页
10.1145/2408776.2408791
评论

性能问题可能是复杂而神秘的，对其起源提供的线索很少或根本没有。在缺乏起始点的情况下，提供一个性能问题的方法通常是随机分析的:猜测问题可能在哪里，然后改变东西，直到问题消失。如果你猜对了，虽然这可以产生结果，但它也可能是耗时的，破坏性的，并可能最终忽略某些问题。本文描述了系统性能问题和目前用于分析这些问题的方法，并提出了一种处理和解决一类问题的新方法。

由于典型系统中组件的数量及其相互作用，系统性能分析是复杂的。环境可以由数据库、Web服务器、负载平衡器和自定义应用程序组成，所有这些都运行在裸金属或虚拟操作系统上。这还只是软件。硬件和固件(包括外部存储系统和网络基础设施)向环境添加了更多的组件，其中任何一个组件都是潜在的问题来源。这些组件中的每一个都可能需要自己的专业领域，而公司可能没有了解其环境中所有组件的员工。

独立工作良好的组件之间的复杂交互也可能导致性能问题。解决这类问题可能需要多个专业领域的合作。

作为环境中这种复杂性的一个例子，考虑一下我们在Joyent为云计算客户遇到的一个神秘的性能问题:这个问题似乎是内存泄漏，但来自未知的位置。在分离的实验室环境中，这是不可复制的。生产环境包括操作系统和系统库、用node.js编写的客户自己的应用程序代码，以及运行在Erlang VM(虚拟机)上的Riak数据库。找到根本原因需要了解客户的代码、node.js、Riak、Erlang和操作系统，每一个都是由一个或多个不同的工程师提供的。有操作系统专业知识的工程师发现问题出在系统库中。

另一个复杂的因素是“好”或“坏”性能可能是主观的:一个用户可能无法接受的延迟对另一个用户来说可能是可以接受的。如果没有明确识别问题的方法，不仅很难知道问题是否存在，而且很难知道问题何时得到解决。度量性能问题的能力，例如，作为响应时间的表达式，可以对性能问题进行量化，并按重要程度对不同问题进行排序。

性能分析方法可以提供一种分析系统或组件并确定问题根源的有效方法，而不需要深入的专业知识。方法学还可以提供识别和量化问题的方法，使人们能够了解问题并对其进行排序。

绩效文本为各种活动提供了方法，例如能力规划、^1，16基准测试,¹⁸和建模系统。^7，8，10然而，寻找性能问题根源的方法并不常见。一个例子是Solaris性能和工具中引入的向下钻取分析方法，¹³它描述了从高级症状到分析原因的三个步骤。这些文本通常通过使用最新技巧和调优的特别检查列表，以及通过教授操作系统内部知识和工具来进行分析。^{2，11，12，15}后者允许性能分析人员开发自己的方法，尽管这可能需要相当长的时间才能完成。

临时性能检查表一直是一种流行的资源。例如,太阳性能和调谐²包括“常用调优技巧的快速参考”，其中列出了11个技巧，旨在发现磁盘瓶颈、网络文件系统(NFS)、内存和CPU问题，易于遵循和规范。支持人员小组经常使用这些列表，因为它们提供了对所有项目的一致检查，包括最严重的问题。然而，这种方法带来了一些问题。可观察性仅限于列表中的特定项目，它们通常是某个时间点的建议，过时了，需要更新。这些检查列表还关注那些已知的补丁可以很容易记录的问题，例如可调参数的设置，但不关注源代码或环境的自定义补丁。

在本文中，我将总结一些系统性能分析的其他方法，包括详细解释的USE方法。我首先描述两个常用的反—方法—指责别人的反方法和路灯反方法，作为与后来的方法的比较。

回到顶部

“要怪别人”Anti-Method

第一个反方法论遵循以下简单步骤:

1. 找到您不负责的系统或环境组件。
2. 假设问题出在那个组件上。
3. 将问题重定向给负责的团队。
4. 如果被证明是错误的，回到第1步。

例如，“也许是网络的问题。你能检查一下网络团队，看看他们是否丢失了数据包或其他什么吗?”

这种方法不是调查性能问题，而是把它们当成其他人的问题，这可能会浪费其他团队的资源。缺乏数据分析，甚至一开始就缺乏数据，导致了这个假设。要求提供显示运行了哪些工具以及如何解释它们的输出的屏幕截图。这些问题可以向其他人征求意见。

回到顶部

的路灯Anti-Method

虽然运行工具和收集数据比狂野的假设更好，但这并不足以进行有效的性能分析，如路灯反方法所示。这是没有任何刻意的方法论。用户通过选择熟悉的、在互联网上找到的或随机找到的可观察性工具来分析性能，然后查看是否有明显的东西出现。这种随意的方法可能会忽略许多类型的问题。

找到合适的工具可能需要一段时间。最熟悉的工具首先运行，即使它们没有什么意义。这与一种叫做路灯的效果，¹⁷以寓言命名的:

一个警察看到一个醉汉在路灯下找东西，就问他在找什么。醉汉说他把钥匙丢了。警察也找不到，问他是不是在路灯下丢的。醉汉回答说:“不，但这里是光线最好的地方。”

性能等效物应该是top(1)，不是因为它有意义，而是因为用户不知道如何读取其他工具。

学习更多的工具会有所帮助，但仍然是一种有限的方法。由于缺乏可观察性工具或指标，某些系统组件或资源可能被忽略。此外，用户不知道视图是不完整的，没有办法识别“未知的未知”。

更好的性能分析方法可以在您运行任何工具之前解决问题。这些包括问题陈述方法、工作负载描述和向下钻取分析。

回到顶部

问题陈述的方法

支持工作人员通常在收集有关问题的信息时使用的问题说明方法已被用于性能分析。⁹它可以是解决性能问题的第一种方法。

目的是收集问题的详细描述和问题陈述，以指导更深入的分析。描述本身甚至可能解决这个问题。这通常通过询问以下问题进入票务系统:

• 是什么让您认为存在性能问题?
• 这个系统曾经运行良好吗?
• 最近发生了什么变化?(软件吗?硬件?负载吗?)
• 性能下降是否可以用延迟或运行时表示?
• 这个问题是否影响到其他人或应用程序(或者仅仅影响到您)?
• 环境是什么?使用什么软件和硬件?版本?配置吗?

这些问题可以根据环境进行定制。虽然这些问题看起来很明显，但答案往往解决了一类问题，不需要更深入的方法。如果不是这样，则可以调用其他方法，包括工作负载描述和向下钻取分析。

回到顶部

工作量表征法

工作负载可以通过回答以下问题来描述:

• 谁造成了负载?进程ID，用户ID，远端IP地址?
• 为什么要调用负载?代码路径?
• 负载的其他特性是什么?IOPS、吞吐量、类型?
• 负载是如何随时间变化的?

这有助于分离架构问题带来的负荷问题通过识别前者。

最好的性能往往来自于消除不必要的工作。有时，这些瓶颈是由应用程序故障(例如，线程卡在循环中)或糟糕的配置(白天运行的系统范围备份)引起的。通过维护或重新配置，可以消除这些不必要的工作。描述负载可以识别这类问题。

回到顶部

深入分析方法

深入分析包括剥离软件和硬件层，以找到问题的核心，从高级视图深入到更深层的细节。这些更深入的细节可能包括检查内核内部，例如，通过使用分析对内核堆栈跟踪进行抽样，或使用动态跟踪检查内核函数的执行。

---

“好”或“坏”的性能可以是主观的:一个用户无法接受的延迟可能对另一个用户来说是可以接受的。如果没有明确识别问题的方法，不仅很难知道问题是否存在，而且很难知道问题何时得到解决。

---

Solaris性能和工具¹³提供系统性能的深入分析方法。它分为三个阶段:

• 监控．随着时间的推移，这将在许多系统中持续记录高级统计信息，如果出现问题，则标识或发出警报。
• 识别．给定一个有可疑问题的系统，这将使用系统工具将调查范围缩小到特定的资源或感兴趣的领域，并确定可能的瓶颈。
• 分析．这个阶段提供了对特定系统领域的进一步检查，确定根本原因并对问题进行量化。

分析阶段可能遵循自己的向下钻取方法，从软件堆栈顶部的应用程序开始，向下钻取到系统库、系统调用、内核内部、设备驱动程序和硬件。

虽然向下钻取分析通常能找出问题的根本原因，但它可能很耗时，而且当钻取方向错误时，会浪费大量时间。

回到顶部

需要一种新的方法论

我最近分析了Joyent公共云上的一个数据库性能问题，该问题始于一个包含问题陈述的票据，如前一节所述。该声明表明，确实存在一个需要深入分析的问题。

这个问题是断断续续的，一些数据库查询需要几秒钟才能完成。客户将此归咎于网络，并假设查询延迟是由丢弃的网络数据包引起的。这并不是一个疯狂的假设，因为票据包括从平(1)表现出偶尔的高延迟;平(1)是一种常见而熟悉的工具，然而，在没有其他支持证据的情况下，这似乎是路灯反方法的一个例子。

支持团队运行工具更详细地研究网络，包括检查TCP/IP堆栈网络计数器，但没有发现任何问题。这个分析需要时间，因为有几十个这样的统计数据，其中一些很难解释，必须随着时间的推移来检查，以寻找相关性。在登录到系统时，团队还检查了CPU使用情况与云计算施加的限制，根据他们自己的常见问题特别检查表。他们的结论是，在他们观察时没有问题:网络和cpu都很好。

在这一点上，许多系统组件和数以万计的系统统计数据还没有被检查，因为它们被认为与问题无关。如果没有可遵循的方向，在客户的云环境中检查所有系统中的所有内容可能需要几天时间。到目前为止，分析还没有发现任何证据表明存在真正的问题，这令人沮丧。

下一步是尝试动态跟踪最初报告的问题(网络数据包丢失)，希望找到标准网络计数器遗漏的东西。我已经多次使用DTrace工具对TCP/IP栈进行下钻分析。这可以提供标准网络可观察性工具集之外的许多细节，包括检查内核丢弃的数据包和内部TCP状态。然而，仍然需要数小时才能捕捉到间歇性的问题。我很想从数据库查询延迟开始深入分析(以防问题与网络无关)，或者开始描述随着时间推移的数据库工作负载(以防问题是由负载激增引起的)，但这些方法也很耗时。

在开始深入分析之前，我想对所有系统组件(不仅仅是网络和cpu)进行快速检查，以查找瓶颈或错误。为了快速检查，每个系统只需要检查有限数量的统计信息，而不是可用的数万个。为了完成这一点，它需要检查所有的组件，包括那些因为默认情况下没有可观察性工具或统计信息而可能被遗漏的组件。

利用、饱和和错误(USE)方法提供了一种实现此目的的方法。它很快显示数据库系统内存不足，正在分页，磁盘偶尔会饱和运行。将故障排除工作早期集中在网络上意味着这些领域在团队的分析中被忽略了。真正的问题在于系统内存和磁盘，它们的读取和解释速度要快得多。

我在教授操作系统性能课程时开发了USE方法。目标是帮助我的学生发现共同的问题，并确保他们没有忽视重要的领域。我在企业和云计算环境中多次成功地使用过它，但它并不能解决所有类型的问题，应该仅仅作为工具箱中的一种方法来对待。

回到顶部

使用方法

USE方法的目的是在性能调查的早期，在问题陈述方法之后使用，以快速识别系统瓶颈。可以总结为:对于每个资源，检查利用率、饱和度和错误．

资源在这种情况下，意味着分别检查所有物理服务器功能组件(cpu、磁盘、总线等)。如果度量有意义，可以使用相同的方法检查一些软件资源。

利用在特定时间间隔内，资源忙于处理工作的时间百分比。虽然繁忙，但资源可能仍然能够接受更多的工作;它不能这样做的程度是由饱和．那些额外的工作通常需要排队等候。

对于某些资源类型，包括主存，利用率是能力所使用资源的。这与基于时间的定义不同。一旦容量资源达到100%的利用率，就不能接受更多的工作，它要么将工作排队(饱和)，要么返回错误，其中任何一种都由USE方法识别。

错误对于USE方法，指的是错误事件的计数。应该调查错误，因为它们会降低性能，而且当故障模式可恢复时，可能不会立即注意到错误。这包括失败并被重试的操作，以及冗余设备池中失败的设备。

与路灯反方法相比，USE方法迭代系统资源，而不是从工具开始。这将创建一个要问的完整问题列表，然后才搜索回答这些问题的工具。即使找不到可以回答这些问题的工具，这些问题没有得到回答的知识对性能分析师来说也是非常有用的:它们现在是“已知的未知”。

USE方法还将分析导向有限数量的关键指标，以便尽可能快地检查所有系统资源。在此之后，如果没有发现问题，您可以转向其他方法。

USE方法的关键指标通常表示如下:

• 利用率在一段时间间隔内的百分比(例如，一个CPU以90%的利用率运行)。
• 饱和度作为等待队列长度(例如，cpu的平均运行队列长度为4)。
• 错误是报告的错误数量(例如，网络接口发生了50次延迟冲突)。

表示测量的时间间隔也很重要。尽管这似乎违反直觉，但短期的高利用率爆发可能导致饱和和性能问题，即使在很长一段时间内总体利用率很低。一些监视工具以5分钟平均值报告利用率。例如，CPU利用率每秒钟都可能发生巨大变化，5分钟的平均时间可以掩盖100%利用率的短时间，从而导致饱和。

USE方法的第一步是创建资源列表。尽量做到完整。下面是服务器硬件资源的通用列表，并提供了具体的示例:

• cpu套接字、内核、硬件线程(虚拟cpu)。
• 主内存DRAM。
• 网络接口以太网端口。
• 存储设备磁盘。
• 控制器存储、网络。
• 互联CPU、内存、I / O。

每个组件通常充当单一资源类型。例如，主存是一种容量资源，而网络接口是一种I/O资源，它可以是IOPS(每秒I/O操作)或吞吐量。有些组件可以表现为多种资源类型，例如，存储设备既是I/O资源又是容量资源。考虑所有可能导致性能瓶颈的类型。还要注意，I/O资源可以进一步研究为排队系统，它们排队，然后为这些请求提供服务。

一些物理组件可以从您的检查清单中删除，例如硬件缓存(例如，MMU TLB/TSB, CPU Level-1/2/3)。对于那些在高利用率或饱和状态下性能下降、导致瓶颈的资源，USE方法是最有效的;缓存改善高利用率下的性能。

在应用USE方法之后，也就是说，在排除了系统瓶颈之后，可以检查缓存命中率和其他性能属性。如果您不确定是否要包含一个资源，请继续并包含它，然后查看度量在实践中工作得如何。

回到顶部

功能块图

另一种遍历资源的方法是查找或绘制功能框图^3.的系统。这种类型的图还显示了关系，这在查找数据流中的瓶颈时非常有用。图1是显示双套接字系统的通用图。

在确定各种总线的利用率时，在功能图上用其最大带宽注释每个总线。结果图可以在进行单个测量之前确定系统瓶颈。(在硬件产品设计期间，这也是一个有用的练习，因为您仍然有时间更改物理组件。)

CPU、内存和I/O互连经常被忽略。幸运的是，它们通常不是系统瓶颈的原因。不幸的是，当它们是这样的时候，问题可能很难解决(也许您可以升级主板或减少负载(例如，“零拷贝”项目减轻内存总线负载)。USE方法至少考虑了互连性能。(请参见HyperTransport分析⁴以这种方式确定的互连问题为例。)

有了资源列表后，考虑每个资源所需的度量类型(利用率、饱和度和错误)。表1列出了一些示例资源和度量类型，以及可能的度量(来自通用的Unix/Linux)。这些指标可以表示为每个区间的平均值或计数。

对所有组合重复，并包括获取每个指标的说明。注意目前还没有可用的指标:这些是“已知的未知数”。最终你会得到一个包含30个指标的列表，其中有些指标很难度量，有些则根本无法度量。已经为基于Linux和solaris的系统构建了示例检查列表。^5，6

幸运的是，最常见的问题通常是在更简单的度量中发现的(例如，CPU饱和、内存容量饱和、网络接口利用率、磁盘利用率)，所以可以先检查这些。

表2列出了一些较难的组合例子。其中一些指标可能无法从标准操作系统工具中获得。我经常必须为这些指标编写自己的软件，使用静态或动态跟踪(DTrace)或CPU性能计数器工具。

可以对一些软件资源进行类似的检查。这通常适用于软件的较小组件，而不是整个应用程序。例如:

• 互斥锁．利用率可以定义为锁被持有的时间，那些排队等待锁的线程的饱和。
• 线程池．利用率可以定义为线程忙于处理工作的时间，饱和是指等待线程池提供服务的请求的数量。
• 进程/线程的能力．系统可能有数量有限的进程或线程，它们的当前使用情况可以定义为利用率;等待分配可能表明饱和;当分配失败时(例如，“不能分叉”)会发生错误。
• 文件描述符的能力．这与上面类似，但适用于文件描述符。

如果指标运行良好，那么就使用它们;否则，软件故障排除可以留给其他方法。

回到顶部

建议的解释

USE方法帮助确定要使用的度量。在学习如何从操作系统读取它们之后，下一个任务是解释它们的当前值。对于某些指标，解释可能是显而易见的(并且有很好的文档)。其他的则不那么明显，可能取决于工作负载需求或期望。以下是解释度量类型的一些一般建议:

• 利用．100%的利用率通常是瓶颈的标志(检查饱和度及其效果以确认)。由于以下几个原因，高利用率(例如，超过60%)可能开始成为一个问题。首先，当在相对较长的一段时间内(数秒或数分钟)测量利用率时，总利用率(比如60%)可以隐藏利用率为100%的短暂爆发。其次，一些系统资源(如硬盘)通常不能在操作期间中断，即使是对优先级较高的工作也是如此。与此相比，cpu几乎随时都可能被中断(“抢占”)。一旦磁盘利用率超过60%，由于队列尾部变长，排队延迟可能会变得更加频繁和明显。这可以通过使用排队理论来建模响应时间与利用率(例如，将磁盘建模为M/M/1)来量化。
• 饱和．任何程度的饱和都可能是一个问题(非零)。这可以用等待队列的长度或在队列上等待的时间来衡量。
• 错误．非零错误计数器值得研究，特别是当性能较差时它们仍在增加。

很容易解释消极的情况:利用率低，没有饱和，没有错误。这比听起来更有用。缩小调查范围可以帮助您快速集中到问题区域。

回到顶部

云计算

在云计算环境中，软件资源控制可能用于限制或限制共享一个系统的租户。在Joyent，我们主要使用操作系统虚拟化(基于smartos的Smart-Machine)，这强加了内存和CPU限制，以及存储I/O限制。每一个资源限制都可以用USE方法检查，类似于检查物理资源。

例如，在我们的环境中内存容量利用率可以是租户的内存使用情况与它的内存上限。内存容量饱和可以通过匿名分页活动看到，即使传统的Unix页面扫描程序可能处于空闲状态。

• 策略．USE方法如图中的流程图所示图2．首先是错误，因为它们通常比利用率和饱和更容易和更快地解释。

USE方法确定可能是系统瓶颈的问题。不幸的是，系统可能有多个性能问题，因此您发现的第一个问题可能是问题，但不是问题本身。在根据需要返回USE方法遍历更多资源之前，可以使用进一步的方法研究每个发现。或者，您可能会发现，首先完成USE方法检查表并列出所发现的所有问题，然后根据可能的优先级对每个问题进行调查更有效。

---

在云计算环境中，软件资源控制可能用于限制或限制共享一个系统的租户。

---

用于进一步分析的方法包括前面总结的工作负载表征方法和向下钻取分析方法。在完成这些操作之后(如果需要的话)，您应该有证据来确定所需要的纠正措施是调整应用的负载还是调优资源本身。

虽然前面的方法可以解决大多数服务器问题，但是基于延迟的方法(例如，方法R¹⁴)可以找到所有问题的100%。但是，如果您不熟悉软件内部结构，这些方法可能会花费更多的时间，而且它们可能更适合已经熟悉这些内容的数据库管理员或应用程序开发人员。

回到顶部

结论

系统性能分析可能是复杂的，任何组件都可能产生问题，包括它们之间的交互。如今常用的方法有时类似于猜测:尝试熟悉的工具或在没有确凿证据的情况下提出假设。

USE方法的开发是为了解决其他常用方法中的缺陷，它是执行系统健康状况完整检查的简单策略。它考虑所有的资源，以避免忽略问题，它使用有限的度量，以便能够快速地跟踪它。这对于包括云计算在内的分布式环境尤其重要，在这种环境中可能需要检查许多系统。然而，这种方法只会发现某些类型的问题(瓶颈和错误)，应该被视为更大的方法工具箱中的一个工具。

回到顶部

致谢

Carry Millsap的方法论研究，包括方法R，是鼓舞人心的，也是我记录系统方法论的动力。感谢Bryan Cantrill对本文的帮助和dtrace的创建，dtrace使得系统方法的开发和实际应用远远超出了传统的可观察性所允许的范围。感谢Deirdré Straughan的编辑和反馈。

相关文章
在queue.acm.org

绩效的代价
路易斯安德烈·巴罗佐
http://queue.acm.org/detail.cfm?id=1095420

性能反模式
巴特Smaalders
http://queue.acm.org/detail.cfm?id=1117403

清晰地思考绩效
卡里-米尔萨普
http://queue.acm.org/detail.cfm?id=1854041

回到顶部

回到顶部

回到顶部

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2013 ACM, Inc.

---

没有发现记录