系统化地思考性能
USE 方法解决了其他常用方法中的不足。
Brendan Gregg，Joyent
性能问题可能既复杂又神秘，几乎不提供任何关于其来源的线索。在缺乏起点或提供起点的方法的情况下，性能问题通常会被随机分析：猜测问题可能在哪里，然后更改某些东西直到问题消失。虽然这可以带来结果——如果你猜对了——但它也可能非常耗时、具有破坏性，并且最终可能会忽略某些问题。本文描述了系统性能问题和当今用于分析这些问题的方法，并提出了一种新的方法来处理和解决一类问题。
系统性能分析之所以复杂，是因为典型系统中组件的数量及其交互作用。一个环境可能由数据库、Web 服务器、负载均衡器和自定义应用程序组成，所有这些都运行在操作系统之上——无论是裸机还是虚拟的。而这仅仅是软件。硬件和固件，包括外部存储系统和网络基础设施，为环境增加了更多组件，其中任何一个都可能是问题的潜在来源。这些组件中的每一个都可能需要其自身的专业领域，而公司可能没有精通其环境中所有组件的员工。
性能问题也可能源于在隔离状态下运行良好的组件之间复杂的交互。解决此类问题可能需要多个领域的专家协同工作。
作为一个环境内复杂性的例子，考虑我们在 Joyent 为云计算客户遇到的一个神秘的性能问题：问题似乎是内存泄漏，但来源未知。这在实验室环境中，组件隔离的情况下无法重现。生产环境包括操作系统和系统库、客户自己用 node.js 编写的应用程序代码，以及在 Erlang VM（虚拟机）上运行的 Riak 数据库。找到根本原因需要了解客户的代码、node.js、Riak、Erlang 和操作系统，这些知识分别由一位或多位不同的工程师提供。问题最终被确定在系统库中，由具有操作系统专业知识的工程师识别出来。
另一个复杂因素是“好”或“坏”的性能可能是主观的：对于一个用户来说不可接受的延迟，对于另一个用户来说可能是可以接受的。在没有明确识别问题的方法的情况下，不仅很难知道是否存在问题，也很难知道问题何时得到解决。衡量性能问题的能力——例如，以响应时间来衡量——使它们能够被量化，并且可以将不同的问题按重要性排序。
性能分析方法可以提供一种有效的方式来分析系统或组件，并识别问题的根本原因，而无需深入的专业知识。方法还可以提供识别和量化问题的方法，使其为人所知并进行排序。
性能文本为各种活动提供了方法，例如容量规划1,16、基准测试18和系统建模7,8,10。然而，用于查找性能问题根本原因的方法并不常见。《Solaris 性能和工具》13中介绍的向下钻取分析方法就是一个例子，该方法描述了一个三阶段过程，用于从高层症状向下移动到分析原因。性能文本通常涵盖通过使用最近提示和调优的临时清单以及教授操作系统内部原理和工具来进行分析2,11,12,15。这使得性能分析师能够开发自己的方法，尽管这可能需要相当长的时间才能完成。
临时性能清单一直是一种流行的资源。《Sun 性能和调优》2包括“常用调优技巧快速参考”，其中列出了 11 个技巧，旨在查找磁盘瓶颈、NFS（网络文件系统）、内存和 CPU 问题，既易于遵循又具有指导性。支持人员组经常使用这些列表，因为它们提供了对所有项目的一致检查，包括最严重的问题。然而，这种方法存在一些问题。可观察性仅限于列表中的特定项目，并且它们通常是过时的即时建议，需要更新。这些清单还侧重于存在已知修复方案且易于记录的问题，例如可调参数的设置，而不是对源代码或环境的自定义修复。
以下各节总结了用于系统性能分析的几种其他方法，包括 USE 方法，将在下文详细解释。让我们首先描述两种常用的反方法——责怪他人反方法和路灯反方法——它们可以作为与后续方法进行比较的参考。
反方法
第一种反方法，责怪他人，遵循以下简单步骤
1. 找到一个您不负责的系统或环境组件。
2. 假设问题出在该组件上。
3. 将问题重定向到负责的团队。
4. 当被证明错误时，返回步骤 1。
例如，“也许是网络问题。您能与网络团队核实一下他们是否有丢包或其他问题吗？”
这种方法不是调查性能问题，而是将其变成别人的问题，这可能会浪费其他团队的资源。缺乏数据分析——甚至一开始就缺乏数据——导致了这种假设。要求提供屏幕截图，显示运行了哪些工具以及如何解释它们的输出。这些可以交给其他人征求第二意见。
虽然运行工具和收集数据比胡乱猜测要好，但它不足以进行有效的性能分析，路灯反方法就证明了这一点。这是一种缺乏任何刻意方法的做法。用户通过选择熟悉的、在互联网上找到的或随机找到的可观察性工具来分析性能，然后看看是否有任何明显的问题出现。这种碰运气的做法可能会忽略许多类型的问题。
找到合适的工具可能需要一段时间。最熟悉的工具会先运行，即使它们不是最合理的选择。这与一种称为路灯效应17的观察偏差有关，该效应以一个寓言命名
一名警察看到一个醉汉在路灯下寻找东西，问他在找什么。醉汉说他丢了钥匙。警察也找不到，就问他是不是在路灯下丢的。醉汉回答说：“不是，但这里的光线最好。”
性能方面的等价物是查看 top(1)，不是因为它有道理，而是因为用户不知道如何读取其他工具。
学习更多工具有所帮助，但仍然是一种有限的方法。某些系统组件或资源可能会因缺乏可观察性工具或指标而被忽略。此外，用户没有意识到视图是不完整的，也无法识别“未知的未知”。
现有的性能分析方法
有更好的性能分析方法可用，可以在您运行任何工具之前解决问题。这些方法包括问题陈述方法、工作负载特征描述和向下钻取分析。
问题陈述方法
问题陈述方法通常由支持人员用于收集有关问题的信息，已被应用于性能分析9。它可以是针对性能问题尝试的第一种方法。
其目的是收集问题的详细描述——问题陈述——以指导更深入的分析。描述本身甚至可以解决问题。这通常通过询问以下问题输入到工单系统中
• 是什么让您认为存在性能问题？
• 此系统是否曾经运行良好？
• 最近发生了什么变化？（软件？硬件？负载？）
• 性能下降是否可以用延迟或运行时来表示？
• 问题是否影响其他人或应用程序（还是仅仅是您）？
• 环境是什么？使用了哪些软件和硬件？版本？配置？
这些问题可以根据环境进行定制。虽然这些问题看起来很明显，但答案通常可以解决一类问题，而无需更深入的方法。当情况并非如此时，可以调用其他方法，包括工作负载特征描述和向下钻取分析。
工作负载特征描述方法
工作负载可以通过回答以下问题来描述
• 谁在造成负载？进程 ID、用户 ID、远程 IP 地址？
• 为什么调用负载？代码路径？
• 负载的其他特征是什么？IOPS、吞吐量、类型？
• 负载如何随时间变化？
这有助于通过识别前者来区分负载问题和架构问题。
最佳的性能提升通常来自于消除不必要的工作。有时，这些瓶颈是由应用程序故障（例如，线程陷入循环）或错误的配置（白天运行的系统级备份）引起的。通过维护或重新配置，可以消除此类不必要的工作。描述负载特征可以识别此类问题。
向下钻取分析方法
向下钻取分析包括剥离软件和硬件的层层，以找到问题的核心——从高层视图移动到更深层次的细节。这些更深层次的细节可能包括检查内核内部原理——例如，通过使用性能分析来采样内核堆栈跟踪，或使用动态跟踪来检查内核函数的执行。
《Solaris 性能和工具》13提供了一种用于系统性能的向下钻取分析方法。它遵循三个阶段
• 监控。 这持续记录许多系统在一段时间内的高层统计数据，识别或警告是否存在问题。
• 识别。 给定一个疑似存在问题的系统，这会将调查范围缩小到使用系统工具的特定资源或感兴趣的领域，并识别可能的瓶颈。
• 分析。 此阶段提供对特定系统区域的进一步检查，识别根本原因并量化问题。
分析阶段可以遵循其自身的向下钻取方法，从软件堆栈顶部的应用程序开始，向下钻取到系统库、系统调用、内核内部原理、设备驱动程序和硬件。
虽然向下钻取分析通常可以精确定位问题的根本原因，但它可能非常耗时，并且当向错误的方向钻取时，可能会浪费大量时间。
对新方法的需求
我最近分析了 Joyent 公有云上的一个数据库性能问题，该问题始于一个包含上一节中描述的问题陈述的工单。该陈述表明存在一个需要更深入分析的实际问题。
该问题是间歇性的，某些数据库查询需要几秒钟才能完成。客户责怪网络，假设查询延迟是由丢包引起的。这不是一个疯狂的假设，因为工单中包含了来自ping(1)的输出，显示偶尔的高延迟；ping(1)但是，ping(1) 是一个常见且熟悉的工具，在没有其他支持证据的情况下，这似乎是路灯反方法的一个例子。
支持团队运行工具更详细地调查了网络，包括检查 TCP/IP 协议栈网络计数器，但没有发现任何问题。这种分析花费了时间，因为有数十个这样的统计数据，其中一些数据难以解释，并且必须随着时间的推移进行检查以寻找相关性。在登录系统时，团队还对照云施加的限制检查了 CPU 使用率，遵循他们自己的常见问题临时清单。他们的结论是，在他们观察期间没有问题：网络和 CPU 都很好。
此时，许多系统组件和数万个系统统计数据尚未检查，因为它们被认为与问题无关。在没有方向可循的情况下，检查客户云环境中所有系统的一切可能需要数天时间。迄今为止的分析没有发现任何实际问题的证据，这令人沮丧。
下一步是尝试对最初报告的问题（丢包）进行动态跟踪，希望找到标准网络计数器遗漏的东西。我曾多次使用 DTrace 工具对 TCP/IP 协议栈进行向下钻取分析。这可以提供超出标准网络可观察性工具集的许多细节，包括检查内核丢弃的数据包和内部 TCP 状态。但是，捕获间歇性问题仍然可能需要数小时。我曾想从数据库查询延迟开始向下钻取分析，以防问题与网络无关，或者开始描述数据库工作负载随时间变化的特征，以防问题是由负载突发引起的，但这些方法也很耗时。
在开始更深入的分析之前，我想快速检查所有系统组件，而不仅仅是网络和 CPU，以查找瓶颈或错误。为了快速完成，它只需要检查每个系统有限数量的统计数据，而不是数万个可用的统计数据。为了完整，它需要检查所有组件，包括那些可能因默认情况下没有可观察性工具或统计数据而被遗漏的组件。
USE 方法提供了一种实现此目的的方法。它很快揭示数据库系统内存不足并正在分页，并且磁盘偶尔以饱和状态运行。早期将故障排除工作重点放在网络上意味着这些领域在团队的分析中被忽略了。真正的问题在于系统内存和磁盘，这些问题更容易读取和解释。
我在教授操作系统性能课程时开发了 USE 方法。目标是帮助我的学生找到常见问题，并确保他们不会忽略重要领域。我已在企业和云计算环境中多次成功使用它，但它并不能解决所有类型的问题，应将其视为工具箱中的一种方法。
USE 方法
USE（利用率、饱和度和错误）方法旨在在性能调查的早期阶段使用，在问题陈述方法之后，以快速识别系统性瓶颈。它可以概括为
对于每个资源，检查利用率、饱和度和错误。
在这种情况下，资源是指所有物理服务器功能组件（CPU、磁盘、总线等），单独检查。某些软件资源可以使用相同的方法进行检查，前提是指标有意义。
利用率是指在特定时间间隔内资源忙于处理工作的时间百分比。当资源繁忙时，它可能仍然能够接受更多的工作；饱和度确定了它无法接受更多工作的程度。额外的工作通常在队列中等待。
对于某些资源类型，包括主内存，利用率是已使用的资源容量。这与基于时间的定义不同。一旦容量资源达到 100% 的利用率，就无法接受更多的工作，它要么将工作排队（饱和），要么返回错误，这两者都可以通过 USE 方法识别出来。
USE 方法中的错误是指错误事件的计数。应该调查错误，因为它们会降低性能，并且当故障模式可恢复时，可能不会立即注意到它们。这包括操作失败并重试，以及冗余设备池中的设备发生故障。
与路灯反方法相反，USE 方法迭代系统资源，而不是从工具开始。这创建了一个完整的要问的问题列表，然后才搜索回答这些问题的工具。即使找不到工具来回答这些问题，对于性能分析师来说，知道这些问题尚未得到解答也可能非常有用：它们现在是“已知的未知”。
USE 方法还将分析导向有限数量的关键指标，以便尽可能快地检查所有系统资源。在此之后，如果没有发现任何问题，您可以转向其他方法。
指标的表达
USE 方法的关键指标通常表示如下
• 利用率，以时间间隔内的百分比表示（例如，一个 CPU 以 90% 的利用率运行）。
• 饱和度，以等待队列长度表示（例如，CPU 的平均运行队列长度为 4）。
• 错误，以报告的错误数表示（例如，网络接口已发生 50 次延迟冲突）。
表达测量的时间间隔也很重要。虽然看起来可能违反直觉，但即使在较长的时间间隔内总体利用率较低，短暂的高利用率也可能导致饱和和性能问题。一些监控工具报告的利用率是五分钟的平均值。例如，CPU 利用率可能每秒钟发生剧烈变化，而五分钟的平均值可能会掩盖短暂的 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 方法考虑了互连性能。（有关以这种方式识别的互连问题的示例，请参见分析 HyperTransport4。）
指标
一旦您有了资源列表，请考虑您需要的每种指标类型（利用率、饱和度和错误）。表 1 列出了一些示例资源和指标类型，以及可能的指标（来自通用 Unix/Linux）。这些指标可以表示为每个间隔的平均值或计数。
对所有组合重复此操作，并包括获取每个指标的说明。记下当前不可用的指标：这些是“已知的未知”。您最终会得到大约 30 个指标的列表，其中一些指标难以测量，而另一些指标根本无法测量。已经为基于 Linux 和 Solaris 的系统构建了示例清单5,6。
幸运的是，最常见的问题通常可以通过更简单的指标找到（例如，CPU 饱和度、内存容量饱和度、网络接口利用率、磁盘利用率），因此可以首先检查这些指标。
更难的指标
表 2 列出了一些更难组合的示例。其中一些指标可能无法从标准操作系统工具获得。我经常必须为这些指标编写自己的软件，使用静态或动态跟踪 (DTrace) 或 CPU 性能计数器工具。
软件资源
可以类似地检查某些软件资源。这通常适用于较小的软件组件，而不是整个应用程序。例如
• 互斥锁。 利用率可以定义为锁被持有的时间，饱和度可以定义为在锁上排队等待的线程。
• 线程池。 利用率可以定义为线程忙于处理工作的时间，饱和度可以定义为等待线程池服务的请求数。
• 进程/线程容量。 系统可能具有有限数量的进程或线程，其当前使用情况可以定义为利用率；等待分配可能表明饱和度；当分配失败时（例如，“无法 fork”）会发生错误。
• 文件描述符容量。 这与上述类似，但适用于文件描述符。
如果这些指标效果良好，则使用它们；否则，软件故障排除可以留给其他方法。
建议的解释
USE 方法有助于识别要使用的指标。在您学习如何从操作系统读取它们之后，您的下一个任务是解释它们的当前值。对于某些指标，解释可能是显而易见的（并且有充分的文档记录）。另一些指标则不太明显，可能取决于工作负载要求或期望。以下是一些解释指标类型的一般建议
• 利用率。 100% 的利用率通常是瓶颈的迹象（检查饱和度及其影响以确认）。高利用率（例如，超过 60%）可能开始成为问题，原因有二。首先，当在相对较长的时间段（多秒或多分钟）内测量利用率时，总利用率（例如）60% 可能会掩盖短暂的 100% 利用率。其次，某些系统资源（例如硬盘）通常在操作期间无法中断，即使是为了更高优先级的工作也是如此。将此与 CPU 进行比较，CPU 几乎可以在任何时候中断（“抢占”）。一旦磁盘利用率超过 60%，排队延迟可能会变得更加频繁和明显，因为队列的尾部会变得更长。这可以使用排队论来量化响应时间与利用率之间的关系（例如，将磁盘建模为 M/M/1）。
• 饱和度。 任何程度的饱和都可能是一个问题（非零）。这可以衡量为等待队列的长度或在队列中等待的时间。
• 错误。 非零错误计数器值得调查，特别是如果它们在性能较差时仍在增加。
很容易解释负面情况：低利用率、无饱和度、无错误。这比听起来更有用。缩小调查范围可以帮助您快速专注于问题区域。
云计算
在云计算环境中，可能会实施软件资源控制来限制或节流共享一个系统的租户。在 Joyent，我们主要使用操作系统虚拟化（基于 SmartOS 的 SmartMachine），它施加内存和 CPU 限制，以及存储 I/O 节流。可以使用 USE 方法检查这些资源限制中的每一个，类似于检查物理资源。
例如，在我们的环境中，内存容量利用率可以是租户的内存使用量与内存上限之比。内存容量饱和度可以通过匿名分页活动来观察，即使传统的 Unix 页面扫描程序可能处于空闲状态。
策略
USE 方法在图 2 中以流程图的形式呈现。错误优先，因为它们通常比利用率和饱和度更容易且更快地解释。
USE 方法识别可能成为系统瓶颈的问题。不幸的是，一个系统可能受到多个性能问题的困扰，因此您发现的第一个问题可能是一个问题，但不是唯一的问题。您可以使用进一步的方法调查每个发现，然后再根据需要返回 USE 方法以迭代更多资源。或者，您可能会发现更有效的方法是首先完成 USE 方法清单并列出发现的所有问题，然后根据其可能的优先级调查每个问题。
进一步分析的方法包括之前总结的工作负载特征描述和向下钻取分析方法。完成这些方法（如果需要）后，您应该有证据确定所需的纠正措施是调整应用的负载还是调整资源本身。
其他方法
虽然以前的方法可能解决大多数服务器问题，但基于延迟的方法（例如，Method R14）可以接近找到 100% 的所有问题。然而，如果您不熟悉软件内部原理，这些方法可能会花费更多时间，并且它们可能更适合已经熟悉这些原理的数据库管理员或应用程序开发人员。
结论
系统性能分析可能很复杂，问题可能来自任何组件，包括组件之间的交互。当今常用的方法有时类似于猜测：尝试熟悉的工具或提出没有确凿证据的假设。
开发 USE 方法是为了解决其他常用方法中的缺点，并且是一种简单的策略，用于对系统健康状况进行全面检查。它考虑了所有资源，以避免忽略问题，并且它使用有限的指标，以便可以快速遵循。这对于分布式环境（包括云计算）尤为重要，在这些环境中可能需要检查许多系统。然而，这种方法只会发现某些类型的问题——瓶颈和错误——应将其视为更大方法工具箱中的一种工具。
参考文献
1. Allspaw, J. 2008. 容量规划的艺术。O'Reilly。
2. Cockcroft, A. 1995. Sun 性能和调优。Prentice Hall。
3. 功能框图； http://en.wikipedia.org/wiki/Function_block_diagram。
4. Gregg, B. 2009. 7410 硬件更新以及 HyperTransport 分析；dtrace.org/blogs/brendan/2009/09/22/7410-hardware-update-and-analyzing-thehypertransport/。
5. Gregg, B. 2012. USE 方法：Linux 性能检查清单；http://dtrace.org/blogs/brendan/2012/03/07/the-use-method-linux-performance-checklist/。
6. Gregg, B. 2012. USE 方法：Solaris 性能检查清单；http://dtrace.org/blogs/brendan/2012/03/01/the-use-method-solaris-performance-checklist/。
7. Gunther, N. 2007. 游击队容量规划。Springer 出版社。
8. Gunther, N. 1997. 实用性能分析师。McGraw Hill 出版社。
9. Hargreaves, A. 2011. 我遇到了性能问题；http://alanhargreaves.wordpress.com/2011/06/27/i-have-a-performance-problem/。
10. Jain, R. 1991. 计算机系统性能分析的艺术。Wiley 出版社。
11. Loukidas, M. 1990. 系统性能调优。O'Reilly 出版社。
12. McDougall, R., Mauro, J. 2006. Solaris 内部原理—Solaris 10 和 OpenSolaris 内核架构。 Prentice Hall 出版社。
13. McDougall, R., Mauro, J., Gregg, B. 2006. Solaris 性能和工具：Solaris 10 和 OpenSolaris 的 DTrace 和 MDB 技术。Prentice Hall 出版社。
14. Millsap, C., Holt, J. 2003. 优化 Oracle 性能。O'Reilly 出版社。
15. Musumeci, G. D., Loukidas, M. 2002. 系统性能调优，第二版。O'Reilly 出版社
16. Schlossnagle, T. 2006. 可扩展的互联网架构。Sams Publishing 出版社。
17. 街灯效应；http://en.wikipedia.org/wiki/Streetlight_effect。
18. Wong, B. 1997. Solaris 服务器的配置和容量规划。Prentice Hall 出版社。
致谢
Carry Millsap 的方法论研究，包括 Method R，一直以来都鼓舞人心，也是我记录系统方法论的动力。感谢 Bryan Cantrill 对本文的帮助，并感谢他创造了 DTrace——这使得系统方法论的开发和实践远远超出了传统可观测性所允许的范围。感谢 Deirdré Straughan 的编辑和反馈。
喜欢还是讨厌？请告诉我们
Brendan Gregg 是 Joyent 的首席性能工程师，他在软件堆栈的任何级别分析性能和可扩展性。他是DTrace (Prentice Hall, 2011) 的主要作者，也是Solaris 性能和工具 (Prentice Hall, 2006) 以及众多系统性能文章的合著者。他之前是 Sun Microsystems 的性能主管和内核工程师，在那里他开发了 ZFS L2ARC。他还开发了许多性能分析工具，包括一些默认在 Mac OS X 和 Oracle Solaris 11 中提供的工具。他最近的工作包括 illumos 和 Linux 内核分析的性能可视化。
© 2012 1542-7730/11/1200 $10.00
最初发表于 Queue vol. 10, no. 12—
在 数字图书馆 中评论这篇文章
更多相关文章
David Collier-Brown - 你不了解关于应用程序性能的一切
每当您遇到性能或容量规划问题时，您都不需要进行全面的基准测试。一个简单的测量将提供您系统的瓶颈点：这个示例程序在每 CPU 每秒八个请求后会明显变慢。这通常足以告诉您最重要的事情：您是否会失败。
Peter Ward, Paul Wankadia, Kavita Guliani - 在 Google 改造后端子集化
后端子集化对于降低成本非常有用，甚至对于在系统限制内运行可能是必要的。十多年来，Google 使用确定性子集化作为其默认后端子集化算法，但是尽管此算法平衡了每个后端任务的连接数，但确定性子集化具有高水平的连接抖动。我们在 Google 的目标是设计一种具有降低的连接抖动的算法，该算法可以替代确定性子集化作为默认后端子集化算法。
Noor Mubeen - 工作负载频率缩放定律 - 推导与验证
本文介绍了与每个 DVFS 子系统级别的工作负载利用率缩放相关的方程式。建立了频率、利用率和缩放因子（其本身随频率变化）之间的关系。这些方程式的验证结果证明是棘手的，因为工作负载固有的利用率也似乎在治理样本的粒度上以未指定的方式变化。因此，应用了一种称为直方图脊线跟踪的新方法。在将 DVFS 视为构建块时，量化缩放影响至关重要。典型应用包括 DVFS 调速器和或影响系统利用率、功耗和性能的其他层。
Theo Schlossnagle - DevOps 世界中的监控
监控看起来可能非常令人感到难以承受。最重要的是要记住，完美永远不应该是更好的敌人。DevOps 使组织内部能够进行高度迭代的改进。如果您没有监控，那就获取一些；获取任何东西。有总比没有好，如果您已经接受了 DevOps，那么您已经签约在一段时间内使其变得更好。
© 保留所有权利。