如何调查瓶颈

本主题介绍如何调查瓶颈的建议过程。

什么是问题根源？

问题根源可能是相关的硬件或软件。 在资源利用不足时，通常意味着系统中某处是瓶颈。 瓶颈可能源于硬件限制，也可能源于软件配置效率低下，也可能同时由这两方面导致。

确定瓶颈是一个渐进式的过程，因此缓解一个问题可能导致发现下一个过程。 本主题的目标就是帮助您科学地确定和缓解这些瓶颈。 系统有可能在短期内以峰值执行。 但为了可承受吞吐量，系统只能按其执行速度最慢的组件的最快速度进行处理。

使用连续方法

瓶颈可能发生在系统的终结点（进入/退出），有时候也会发生在中间（业务流程/数据库）。 在确定瓶颈位置后，可以采用结构化的方法来标识问题根源。 在缓解了瓶颈问题后，需要再次测量性能，以确保没有在系统的其他地方造成新的瓶颈。

标识和解决瓶颈的过程应该以连续的方式进行，因此一次只应对一个参数进行变化，然后对性能进行测量以验证这一单个变化的影响。 一次变化多个参数可能会掩盖更改结果。

例如，尽管更改参数 1 可能会改善性能，但如果更改参数 1 时还一同更改了参数 2，则可能会产生抵消更改参数 1 所带来的好处的负面影响，因此导致正负抵消的零效果。 而且，也可能会造成改变参数 1 会带来负面效果、而改变参数 2 会带来正面效果的完全虚假的印象。

测试一致性

在更改设置后测量性能有利于验证更改的效果。

• 硬件：使用一致的硬件非常重要，因为改变硬件可能会显示不一致的行为，从而产生误导性的结果，例如不使用笔记本电脑。

• 测试运行持续时间：在固定的最短时间段内测量性能也很重要，以确保结果确实是可持续的，而不仅仅是峰值。 执行较长时间段的测试的另一个原因是：确保系统经历热启动/突增期间（此期间中，所有缓存都被填满，数据库表达到预期计数，并在达到预定义的阈值后有足够时间进行限流和调整吞吐量）。 此方法将有助于发现最佳可承受吞吐量。

• 测试参数：还必须不要将测试参数从测试运行更改为测试运行。 例如，改变映射复杂性和/或文档大小可能产生不同的吞吐量和延迟结果。

• 干净状态：测试完成后，在运行下一个测试运行之前清理所有状态非常重要。 例如，历史数据可能会在数据库中累积，从而影响运行时吞吐量。 回收服务实例有助于释放缓存的资源，例如内存、数据库连接和线程。

预期：吞吐量与延迟

用户期望已部署系统中具备一定的吞吐量和/或具体的延迟时间顺理成章； 但期望吞吐量很高、而延迟时间还很短，未免太得陇望蜀了。 不过，期望获得最佳吞吐量且具有合理的延迟时间却切实可行。 随着吞吐量的增加，系统也面临越来越高的压力（更高的 CPU 消耗量、更多的磁盘 IO 争用、内存压力、更多的锁定争用），这些压力可能导致对延迟时间造成负面影响。 若要发现最佳系统容量，必须找到并缓解所有瓶颈。

出现瓶颈的原因可能是旧数据 (未清除的数据库中驻留) 已完成的实例。发生这种情况时，性能可能会降低。 给予系统充足的清空时间可能有助于缓解此问题。 但是，发现导致积压累积的原因并帮助缓解这一问题十分重要。

为了发现积压的原因，一定要分析历史数据和监视性能监视器计数器（为了发现使用方案和诊断积压的根源）。 会出现积压的常见情形是：在每晚以批处理方式处理大量数据时。 通过发现系统容量以及能否从积压中恢复，可有助于评估处理过载情况的硬件要求以及在系统为处理意外吞吐量突增而留出的缓冲空间量。

优化系统以获得最佳可承受吞吐量要求用户深入理解要部署的应用程序、系统的优缺点以及特定情况下的使用模式。 发现瓶颈和准确预测最佳可承受吞吐量的唯一方式就是通过对非常契合生产中使用情况的拓扑结构进行全面测试。

本部分中的其他主题引导您完成定义该拓扑结构的过程，并且提供有关如何缓解瓶颈和从一开始就避免瓶颈的指南。

扩展

在部署的拓扑结构的各个阶段都可能发生瓶颈。 某些瓶颈可通过升级硬件得以缓解。 可通过向上扩展（更多的 CPU、内存或缓存）或向外扩展（更多的服务器）对硬件进行升级。 是纵向扩展还是横向扩展取决于所遇到的瓶颈类型和要配置的应用程序。 以下内容介绍如何基于遇到的瓶颈更改硬件部署的拓扑结构。 需要从头开始构建应用程序，以便能够利用纵向扩展/横向扩展的优势。例如：

• 如果应用程序是序列化的并且依赖于单个线程执行，则通过增加 CPU 和/或内存的向上扩展服务器可能不会有助于缓解这一问题。

• 如果更多服务器只会加重对无法扩展的公共资源的争用情况，则使用更多服务器的向外扩展可能起不到帮助作用。 不过，向外扩展还另有好处。 部署两个双处理器服务器而不是一个四处理器服务器可有助于提供冗余的服务器，起到处理增加的吞吐量并提供高度可用拓扑结构的双重扩展作用。