PDF现代性能监控
当今多元化和分散化的计算机世界对性能监控和分析提出了新的思考。
MARK PURDY，PURSOFT
现代Unix服务器机房可能是一个由多家供应商的硬件和多个来源的软件组成的多元宇宙。通常，解决服务器机房性能问题所需的人员不可用，或者出于安全原因，不允许在事件发生的当下在场。即使幸运的是，合适的人员确实在场目睹了性能“事件”，但传统上用于测量和分析硬件和软件性能的工具却很少且特定于供应商。由于几乎没有真正的Unix跨平台工具包存在，因此管理员没有标准方法来准确查看事件、记录以供以后分析或与更多合格人员共享以实现高效的解决。
追踪延迟
研究Unix服务器环境性能的第一步是追踪任何应用程序从用户请求事件到最终屏幕绘制的事务延迟。下一步是绘制服务器拓扑图。为此，许多因素成为问题：网络拓扑、数据库更新（和锁）、磁盘阵列、进程调度、CPU性能、内存亲和性以及驱动程序/中断服务时间。然后，您可以使用一套性能分析工具来研究沿测量事务延迟的完整路径的硬件和软件环境。用户事务的每个部分的这种逐步分解应揭示体验到延迟的元素。性能分析工具包应测量这些元素以及与之相关的性能下降。
应该详细研究用户线程，因为它与事务以及解决用户查询所需路径有关。调整系统延迟时，应遵循两个步骤：首先，定义用户事务必须执行的每个步骤以满足用户请求；然后为每个步骤计时。虽然看似简单，但在多节点事务环境中可能非常困难。一个问题是找到准确的时间基准。NTP（网络时间协议）通常最适合计时节点间网络延迟。一旦在机器上，CPU的时间基准（nanosleep）应该足够。必须尽可能准确地定义每个步骤。每个步骤都包括每个数据包迁移、每个数据包到进程的切换、每个磁盘设备交互以及每个网络交互。必须在每个步骤记录时间戳并保存以供分析。来自延迟研究的这些时间戳将识别服务器环境中需要使用性能工具包检查的区域。
应该监控什么？操作系统允许的一切！
您必须决定在哪里以及要监控什么。这可以从刚刚定义的系统事务延迟研究中收集。您还可以监控和分析服务用户事务的每个组件，并简单地使每个组件尽可能快。最后，您会得到一个设备和进程列表，然后您必须找到合适的方法来计量感兴趣的项目。
简而言之，Unix计算机具有性能分析器感兴趣的五类可测量数据对象：全局、CPU、网络接口、磁盘和进程。前四类描述了用户Unix计算机的物理属性。全局类别描述了内存、分页和交换特性；全局文件系统内存使用情况；以及其他项目，例如时间、运行时间和负载平均值。CPU类别包含物理项目，例如使用率、中断、陷阱、交叉调用以及其他Unix项目，例如设备读取/写入和进程迁移。网络类别包括物理接口层及其组件，以及逻辑TCP/IP层，包括套接字使用项目。磁盘类别包括物理磁盘设备计量数据项、来自CPU的互连和通道数据项。所有这些的基础是磁盘阵列的拓扑结构，通常对CPU的视角是隐藏的。这增加了另一层抽象，在从基于CPU的性能计量工具测量磁盘I/O性能时必须考虑在内。这四个类别描述了Unix对硬件世界的看法。
最后一类是进程层，这是最先感受到监控需求的地方。例如，用户可能会抱怨响应时间慢。无论是CPU运行过热还是“那边”的数据库CPU比正常情况慢，事件的第一个点是注意到瓶颈的进程。然后，问题就变成了在哪里、什么以及如何计量注册延迟事件的对象。
选择合适的工具包——过去和现在
传统上使用的常见Unix性能工具是众所周知的，并且相当有限。大多数软件工程师都熟悉sar、vmstat、iostat和netstat，以及其他类似格式的特定于供应商的工具。一个有用的工具源于Sun世界，是由Adrian Cockcroft和Rich Pettit创建的SymbEL。然而，总的来说，来自并行、多线程应用程序系统中所有资产的平稳响应时间需要比传统Unix工具集中可用的更全面的性能工具。
性能监控的首要关注点是采样时间。大多数第三方工具都面向服务器场，并收集粗粒度的性能数据，用于容量规划和服务器负载热点分析。对于衡量当今分布式环境中应用程序性能的人员来说，有用的采样时间与容量规划人员所需的采样时间不同。成功的性能监控和分析需要细粒度的定时软件和硬件工程工具。这些工具更难找到。这就是过去我如此严重依赖SymbEL工具来“热启动”实时数据库环境的原因之一。
那么问题就变成了：什么是粗粒度，什么是细粒度？我们将粗粒度定义为以5到30秒或更长时间间隔采集和存储或显示的样本。细粒度指的是十分之一秒到五秒的样本。对于担心事务延迟的软件工程师来说，需要一秒或更短的时间——尤其是在大型并行SMP（对称多处理）系统中。这些系统可能每秒有数万个事务，并且可能需要从输入数据包到达用户数据交付的延迟为八毫秒或更短。随着处理器继续进入千兆赫兹领域，可以在服务器上完成有用的亚秒级采样。可以支持如此细粒度采样时间的监控系统的唯一缺点是，当您决定将所有这些性能数据收集到日志格式并将其存储到磁盘时。这种分辨率的日志可能很大。（稍后在本文中，我将讨论智能日志记录提供的强大功能以及为什么这是一个可以接受的权衡。）我最近在以一秒间隔将细粒度Unix性能数据记录到磁盘的努力表明：具有16个网络接口和128个磁盘驱动器且运行4,096个进程的72处理器机器的所有性能数据需要每秒四兆字节的日志写入。
服务器环境中的示例问题集
作为一个例子，让我们检查一下许多Unix工程师面临的通用问题集。它围绕着在磁盘阵列（可能在SAN（存储区域网络）环境中）上定义用户文件系统所涉及的硬件。服务器机房中的这个难题有几个部分。在其最简单的形式中，文件系统是在磁盘阵列或一组磁盘阵列中的多个物理磁盘资产上定义的。从主机上可以看到文件系统的磁盘有三种方式：从主机到磁盘阵列的互连；磁盘阵列本身；以及呈现给主机系统作为物理单元的磁盘切片（或磁盘阵列定义的条带）。从主机上，我们可以看到可以用作条带集中的元素的物理元素。该元素中隐含的通常是到该物理磁盘单元的路径，但某些系统使用多路径驱动程序来使情况复杂化。大多数Unix工具可以看到整个文件系统或单个磁盘，但很少有工具可以显示文件系统和用于构建该文件系统的元素的性能。这至关重要，因为性能下降可能发生在信号链中的任何点。SAN环境中可能存在通道故障、性能下降或交换机问题。根据问题的类型，任何元素都会受到不同的影响。
磁盘最有用的计量标准是平均服务时间。通道路径上的间歇性故障可能是由松动的SCSI连接器、扭曲的光纤电缆、意外关闭的缓存（通常由Unix管理员或现场服务人员造成）以及众多的SAN和光纤交换机问题引起的。它们通常表现为以服务时间衡量的长磁盘延迟。真正的问题是找到文件系统中性能不佳的物理元素，并隔离导致延迟的条件。现成的RICHPse SymbEL工具zoom.se允许工程师发现物理磁盘单元。RulesEngine在物理磁盘上显示图标，不同的颜色表示服务时间的严重程度。显然，红色表示坏（即，服务时间长）；绿色表示正常；白色表示磁盘上没有活动。
此问题的更好解决方案
用户可以编写额外的RICHPse脚本，以帮助提高在性能工具中定义条带集的能力。基本功能已经在RICHPse安装集中提供了一段时间。基本上，它允许对元设备的字节读取/写入和物理磁盘元素的服务时间进行时间序列测量。这可以通过基于主机的条带管理软件（如Veritas或DiskSuite）查看。编写进一步的脚本，使用户可以选择条带的所有单个元素，并查看读取/写入和服务时间，并以时间序列格式呈现数据，使用户可以轻松发现性能异常。然后，这可以快速将用户指向缓存阵列、通道、SAN环境、交换机、共享磁盘阵列资源等。此外，此脚本的相同条带集和元设备定义允许用户对CPU（处理器集密集型应用程序）和网络接口（多IP和IP中继器）执行类似的操作。然后，用户可以在现场捕获此类事件、记录它，并在GUI中稍后读取日志，使记录的服务器看起来好像处于实时状态。
在图1所示的示例中，延迟研究确定，在用户事务中，特定的数据库交互不及时，或者特定的逻辑文件系统及其物理元素未按要求执行。更全面的性能工具包应找到问题硬件或阵列配置错误。数据库事务延迟的软件视图通常显示合理的性能，但并非始终一致。在此示例中，当构建多主机共享磁盘阵列时，物理磁盘被切割成10个切片——五个磁盘，每个磁盘有两个切片。七个切片被分配用于构建服务器A的文件系统。服务器B的文件系统使用跨越两个物理磁盘的三个切片。服务器B对一个共享磁盘的零星使用会导致服务器A的文件系统出现性能下降。这是延迟研究中体验到的症状。工具包显示的性能症状是磁盘I/O速率和服务时间不规则，并且在正确解释数据后，会导致共享磁盘问题。
对“搜索交叉条带集的磁盘元素”事件的分析将随时随地标记出这种弊病。具有此功能的工具包允许用户以任何物理视角对条带集或磁盘阵列进行建模。用户可能需要检查通道拓扑以进行负载平衡，或者检查阵列或SAN拓扑中的两个条带集以进行物理设备交互。通用的服务器机房磁盘阵列和SAN工具仍在发展中，因为人们正在定义拓扑结构。这需要同样发展的性能分析工具。
服务器环境中的进程问题
我遇到的另一个问题与可疑的数据库更新线程有关（图2）。有问题的线程与实时数据库中的其他数百个重型和轻型线程一起运行。与许多应用程序一样，每个工作日都有一个或多个小时的活动高峰期。该线程检查数据库状态和传入数据，以制定服务器机房中其他数据库环境的数据库更新。此线程是数据库服务器上计算特定数据类别的数百个线程之一。此线程中有三个更新生成源。第一个更新源是当前数据库状态。第二个源是实时更新。这些更新是从外部源通过一组前端通信计算机接收的。第三个更新源包括来自多个用户事务处理机器及其本地数据库的检查。检查了所有需要的数据。对本地数据库环境执行了更新，并将这些更新排队以广播到其他几个数据库服务器机器。
第一个用户关注来自此线程的更新使用者之一，发生在持续高峰活动期间。负责该进程的软件工程师被召来分析此问题。当此线程变慢时，用户数据库线程将显示性能下降。虽然有多个数据库服务器，但只有开启此进程的服务器才存在性能问题。当软件工程师检查代码时，我们开始分析受影响服务器（进程开启）和未受影响服务器（进程关闭）的磁盘阵列性能。
很明显，开启更新模式进程的服务器的文件系统磁盘的服务时间存在问题。阵列I/O速率的图形表示也存在显着差异。性能良好的服务器具有平滑的图形，而性能不佳的服务器则断断续续，表明存在橡皮管颈现象。当磁盘阵列的后端无法像服务器更新磁盘阵列的缓存一样快速地将缓存解除暂存到物理介质时，就会发生磁盘阵列橡皮管颈现象。通常，大多数磁盘阵列都具有控制阵列缓存的高/低水位线参数。当达到高水位线时，磁盘阵列的CPU会停止来自服务器的传入I/O请求，并将I/O块从缓存解除暂存到物理介质，直到达到低水位线。然后会爆发I/O速率，直到达到高水位线。这种性能在I/O速率和传输服务时间的时间序列图表上看起来像橡皮管颈现象。经过仔细检查，磁盘阵列的统计信息显示，性能较差的服务器上的缓存解除暂存次数更多。
然后，我们开始研究接触该文件系统的线程的I/O速率，并发现最初指示的更新进程会偶尔将大量内存写入磁盘。这就是问题所在。该软件按设计运行，并且每隔一定数量的更新就会将其进程检查点到磁盘。当系统繁忙时，检查点活动增加，直到磁盘阵列缓存中存在太多脏页。一旦磁盘阵列缓存溢出，许多其他进程都会变慢。
修复方法是重新设计更新线程的检查点逻辑。我们制定了几种修复方法来减少检查点操作的影响。一种修复方法是将触发检查点的事件数阈值切换为时间间隔检查点触发器。第二个修复方法是消除一些检查点数据。随着整体数据库环境的发展，全局数据库检查点和使用重新同步重新启动变得更加强大，从而消除了15年前的应用程序中对本地每个进程检查点逻辑的一些需求。对两个服务器磁盘阵列的高分辨率分析是导致此修复的关键信息。
使用性能监控工具包的现代支持网络
前两个示例具有一个共同的整体拓扑结构，这增加了它们的固有复杂性。典型的大型服务器机房的当前状态是，资产通常位于不同的位置，有时在全球范围内，这是有实际原因的。图3所示的支持图虽然是通用的，但描述了典型的商业服务器机房。在我最近的职业经历中，我有两个服务器机房，每个机房都有多台服务器。我管理的支持和编程人员位于距离服务器很远的地方。他们的工作站在图中顶部表示。我还有一个本地服务器用于“源代码NFS加编译&链接”以及用于核心文件和我的团队当前感兴趣的性能日志的磁盘空间。这些都由图中的“支持服务器”框表示。每个机房的LogHost服务器存储来自任何发生某种形式的性能事件的服务器的所有数据。这包括核心文件和性能日志，这两者都非常大，不应保留在本地服务器上。Unix管理员通常管理LogHost并控制对其数据的访问。这对于管理事件跟踪和确保向适当的各方提供解决性能事件所需的数据是必要的。在安全环境中，LogHost服务器可以允许支持人员访问核心文件和日志，而无需接触服务器LAN。
图3中的支持图是一个相当典型的企业服务器模型。它显示了支持矩阵的基本要素，并且可以向上扩展以容纳更多支持节点、更多服务器机房或每个机房更多服务器。但是，基本结构保持不变。许多Unix管理员和软件/硬件工程师定制他们的“产品”，以提供满足此环境中硬件和软件用户所需的性能指标。
适用于所有服务器环境的一个工具包
功能齐全的工具包必须满足工程师在当今运营的许多不同环境。如图3所示，大多数商业安装通常是独立的子网，工程师有时与物理机器分离。可能有几组物理机器需要支持。我有17台E10K Sun机器以及两个独立服务器机房中的开发服务器。我的直接应用程序仅代表公司服务器环境物理资产的一小部分。计算机服务器机房建筑物相隔40英里，用于多电源网格访问和冗余。支持环境（程序员和Unix支持）位于距离计算机机房数英里的另一栋建筑物中。与向环境提供硬件和软件的各个供应商也存在支持事件。那时甚至今天，很少有工具可以提供保持所有这些机器正常运行所需的性能指标视图。我很快构建了一套RICHPse工具来与大型Sun E10K服务器（17台）一起使用。这些仍然是面向单服务器的工具。我没有通用的工具集来管理和排除多个服务器云的故障。
我继续编写并最近完成了一个工具集，PurSoft Analyst，其目标是解决我多年来面临的所有性能监控问题。我希望各种Unix环境现在可以从我多年的挫败感中受益。在编写此性能分析工具包时，我觉得特别重要的是，无论数据来自实时线程还是磁盘日志文件，呈现给GUI的数据看起来都完全相同。GUI能够以文本表格显示数据，其中布局具有用户可配置的数据显示，或以图形方式呈现为时间序列显示。这允许用户更详细地呈现和检查用户选择的特定数据项。这在结构上类似于市场上的一些容量规划和管理软件包，但响应速度更快。
此工具包中的一个主要组件是CLI（命令行界面）风格的日志记录二进制文件，可以在任何服务器上远程运行。机器的所有指标都被记录下来以供延迟分析。问题和事件有一个不好的习惯，即在您最不期望的时候、随机地或仅在满足某些条件时才会显现出来。24/7全天候在计算机前工作以实时处理许多问题是不切实际的。日志记录工具可以捕获系统崩溃、按特定时间安排或在满足某些用户可设置条件时快照机器活动。日志可以累积并编目到某个地方，以供支持中心分析或供选定的供应商系统工程师分析。这种细粒度的定时性能日志记录工具向主要的商业Unix供应商和机房的Unix工程师呈现相同的外观和感觉。因此，参与此服务器事件的所有参与者——工程师、顾问和管理员——都可以共享事件指标的相同视图。每个参与者都可以使用GUI读取服务器事件的同一日志文件，该GUI将日志呈现为实时状态。由于GUI日志读取器工具使用类似磁带录音机的传输控制，因此它能够“播放”来自日志文件的记录服务器的性能。故障排除人员可以暂停、倒带、快进和循环日志中的区域，以快速专注于问题区域。
此性能工具包的另一个功能是分析工具，可帮助工程师找到采样Unix数据中与任何用户定义的基线不一致的任何项目。此分析器可以定义一个RulesEngine，它可以监听计算机并在某些参数超出范围时报告。此概念的一个示例是SymbEL工具包中的RulesEngine。RICHPse库（用SymbEL编写）具有一个工具，
liverules.se，它为所有RICHPse SymbEL应用程序脚本（如zoom.se）实现RulesEngine。SymbEL语言与C语言非常相似，具有一些扩展和限制，但任何C程序员都可以轻松编写或修改RICHPse工具。此工具集最好的功能之一是Rules工具。用户可以修改liverules.se库以实现特定硬件环境的配置文件。
这些工具的源代码太大，无法在此处正确说明，但在Web上免费提供。RICHPse是一个解释器；因此，在具有许多CPU的旧机器上，它会消耗相当大的开销。理想的解决方案是考虑到效率而二进制编码的。此二进制文件应该是“几乎看不到和听不到的”，除了RulesEngine异常。我可以根据设置的分析规则调用我开发的磁盘日志记录二进制文件。然后，当RulesEngine检测到异常情况时，日志记录将打开。然后，支持工程师可以像以前一样，在稍后的时间和地点分析记录的性能数据。
未来已来
展望未来，人工智能风格的分析将使我们更接近实时问题确定，因为分析器应该能够检测硬件或软件差异与用户可设置的阈值，扫描进程数据，并确定导致事件的进程。例如，检测到I/O热点并进行扫描以确定某些用户应用程序线程当时正在活动地执行I/O。然后可以直接对执行I/O调用的那些线程采取行动。这是我们都手动完成的过程，但它应该是可以自动化的过程。使用我提出的系统，服务器场的Unix管理员将拥有一个工具包，该工具包允许使用AI事件捕获软件定位事件，并捕获有关事件的所有必要数据。当我们使用如此高度可调的分析器来增强服务器日志记录时，我们将有能力在恰当的时间收集日志。这将使日志特别强大，因为有效的分析可以立即在检查时开始。Unix管理员无需搜索可疑事件；它在日志的开头就被捕获到了。然后，他们可以将立即可见的问题转发给最适合修复事件的各方。这可能是任何人，从CPU和子系统供应商工程师到应用程序软件设计师。凭借这种多平台互操作性，世界各地的系统管理员和故障排除人员将首次拥有一套标准化的工具来快速有效地解决性能问题。
MARK D. PURDY是彭博有限合伙公司的原始计算机行情系统架构师。除了建立和管理彭博组织因其18年任期而闻名的行情系统环境外，他的遗产还通过实施基于Sun Microsystems E15K的实时时间序列数据库引擎得到补充，该引擎能够以每秒60,000次更新和每秒5,000次用户事务的速度运行实时监控流。现在是彭博有限合伙公司的半退休合伙人，他在PurSoft Inc.的努力促成了完整的服务器机房系统监控和分析工具的创建，旨在在多样化的大规模计算机环境中提供峰值全局性能。
最初发表于Queue vol. 4, no. 1—
在数字图书馆评论本文
更多相关文章
David Collier-Brown - 你不了解应用程序性能
当您遇到性能或容量规划问题时，您无需进行全面的基准测试。一个简单的测量将提供您系统的瓶颈点：这个示例程序在每CPU每秒八个请求后将显着变慢。这通常足以告诉您最重要的事情：您是否会失败。
Peter Ward, Paul Wankadia, Kavita Guliani - 重塑谷歌的后端子集化
后端子集化对于降低成本非常有用，甚至对于在系统限制内运行可能是必要的。十多年来，谷歌使用确定性子集化作为其默认后端子集化算法，但尽管此算法平衡了每个后端任务的连接数，但确定性子集化具有高水平的连接抖动。我们在谷歌的目标是设计一种具有减少连接抖动的算法，该算法可以取代确定性子集化作为默认后端子集化算法。
Noor Mubeen - 工作负载频率缩放定律 - 推导与验证
本文介绍了与每个DVFS子系统级别的工作负载利用率缩放相关的方程。建立了频率、利用率和缩放因子（其本身随频率变化）之间的关系。这些方程的验证结果证明是棘手的，因为工作负载固有的利用率也似乎在治理样本的粒度上以未指定的方式变化。因此，应用了一种称为直方图脊迹的新颖方法。在将DVFS视为构建块时，量化缩放影响至关重要。典型应用包括DVFS调速器和/或其他影响系统利用率、功耗和性能的层。
Theo Schlossnagle - DevOps世界中的监控
监控可能看起来非常繁琐。最重要的事情是要记住，完美永远不应该是更好的敌人。DevOps使组织内能够进行高度迭代的改进。如果您没有监控，请获得一些；获得任何东西。有些总比没有好，如果您已经接受了DevOps，那么您已经注册了随着时间的推移使其变得更好。
© 保留所有权利。