骑上川崎重工的机器山羊，变身科技牛仔
06-21
简介 当你登录到可能存在性能问题的服务器时，你会/应该做什么？如何进行初步性能分析？本文要介绍的USE方法是一种分析性能问题的方法。它通过执行一系列检查项命令帮助我们识别资源瓶颈和系统错误。
就像飞行手册中的紧急检查表一样，它的设计简单、直接、完整、快捷。 USE 方法 USE 方法的 USE 是利用率、饱和度和错误的首字母之和，意思是：“对于每个资源，检查使用率、饱和度和错误情况”。
其目的是今天早上执行性能检查。并发现系统瓶颈。
首先明确一些概念： 资源：服务器上的物理资源，如CPU、磁盘等；利用率：资源执行服务工作的平均时间；饱和：资源无法提供额外的工作（通常表现为排队）；错误条件（errors）：错误事件发生的情况；利用率还有一个概念，就是已使用资源的比例。在这种情况下，％利用率意味着无法使用更多资源。
对于这些概念，我们通常有以下指标： 利用率：一段时间内的百分比，例如CPU使用率为90%；饱和度：作为队列长度，例如“平均CPU Run队列长度为4”；错误：标量计数。例如，“此网络接口已发生五十次后期冲突”；资源资源列表。
在开始USE方法之前，我们首先要知道机器上有哪些资源： CPU：套接字、核心、硬件线程（硬件线程） Memory：资源容量 Network：网络接口 storage device：I/O、容量控制器：存储、网络卡连接（Interconnects）：CPU、内存、I/O 有些资源是两种类型的资源：存储设备是一种服务请求资源（I/O），它也是一种容量资源。这两种类型都可能成为系统的瓶颈。
请求资源可以被定义为一个排队系统，其中请求首先排队，然后提供服务。这里我们忽略像硬件缓存这样的物理组件，因为USE方法对于在高利用率或饱和情况下性能下降、造成瓶颈的资源最有效，而缓存可以帮助我们在高利用率下提高性能。
消除系统瓶颈后，可以通过USE方法检查缓存命中率和其他性能属性。功能框架图 获取资源列表的另一种方法是查找或绘制系统的功能框架图。
我们不仅可以了解资源情况，还可以了解数据流向。例如，下面是Sun Fire V对应的功能框架图： Sun Fire V 通过这样的功能框架图，我们可以了解机器整体的运行情况。
在确定各种总线的利用率时，我们可以在功能图上标记每个总线的最大带宽。这样我们就可以得到一个图标，这或许可以让我们提前发现系统的瓶颈在哪里。
互连 CPU、内存和 I/O 之间的连接经常被忽视。幸运的是，这通常不是系统瓶颈。
不幸的是，如果是系统瓶颈，就很难优化。使用率低是否意味着饱和度不足？如果使用率在很长一段时间内非常低，但偶尔会变得非常高，则可能会出现饱和。
因此，低使用率并不意味着它还没有饱和。另外，在某些场景下，某些资源已经饱和，导致其他资源利用率较低。
例如，在高 I/O 场景下，如果磁盘饱和，CPU 可能会饿死。云计算环境的资源在云计算环境中，租户使用的系统资源可能受到限制。
所以在这种情况下，我们需要考虑租户的资源限制，而不是全局。指标给定资源，我们需要考虑三个监控类别：使用情况、饱和度和错误条件。
以下是一些示例。读者可以先尝试填写，看看可以用什么指标来描述这些属性： Metrics 注：这些指标要么是每个时间间隔的平均值，要么是计数。
例如，我们可以使用top等工具来获取CPU使用率数据。那么我们可以用什么来指示CPU饱和度呢？下图是完整列表： Metrics 可以看到，对于使用情况，我们一般使用使用情况、资源容量等指标来量化；对于饱和，我们经常使用饱和后的动作。
量化来说，比如CPU饱和时会发生排队，内存饱和时会发生分页。 Harder Metrics 我们来思考一些更难量化的指标：Harder Metrics 读者可以尝试多思考，比如我们应该如何判断CPU是否有错误？ CPU 错误有哪些症状？我们如何量化这些表示？我们将在本文末尾公布结果。
也许这里最简单的一个是内存错误。赶紧想一想，经常出现的错误是什么。
通过检查资源使用情况、饱和度和错误情况，我们将得到大约三十个指标的列表。有些指标很容易获取，比如CPU使用率，而另一些指标则不太容易获取。
幸运的是，最常见的问题很容易找到，我们可以借助现有工具快速找到大多数问题。对于检查项目，Gregg整理了针对不同系统的检查项目清单，可以在附录中找到。
在实际应用中，读取检查表上操作系统上的所有指标可能会非常耗时，而且我们可能只有时间检查部分指标：CPU、内存容量、存储容量、网络接口等。这也是这是一个非常好的尝试，因为我们借助 USE 方法将未知的未知数变成了已知的未知数。
当我们需要找出性能瓶颈时，我们有一个检查项列表可以用来帮助我们分析。软件资源 对于一些软件资源，我们也可以用类似的方法来探究，比如： 互斥锁：使用情况可以定义为持有锁的时间；等待锁的线程饱和；线程池（thread pool）：利用率可以定义为一个线程忙于处理工作的时间；等待线程池服务的请求数量饱和；文件描述符容量：上面建议的 USE 方法的解释可以帮助我们弄清楚要获取哪些指标。
现在我们知道如何从操作系统获取这些指标，我们需要解释这些值。对于某些值，解释是显而易见的；对于某些人，我们可能需要根据特定的工作负载和期望进行解释。
以下是建议的指标解释的一些示例： 利用率：100% 使用率通常是性能瓶颈的标志，我们需要仔细检查饱和度水平。由于多种原因，高利用率（例如，大于 70%）可能会成为一个问题： 在测量相对较长时间段内的利用率时，高利用率可能会隐藏 100% 利用率的短期峰值。
;某些系统资源（例如磁盘）在运行过程中不能中断。一旦利用率超过70%，排队延迟就会变得更加明显和频繁；饱和情况：任何程度的饱和都可能成为问题。
我们可以通过等待队列的长度或者在队列中等待的时间来衡量；错误情况：非零错误计数器值得研究，特别是在性能不佳的情况下它们仍然增加。使用该策略，我们可以将其基于如下流程图。
让我们将 USE 方法付诸实践：USE 方法在检测使用情况和饱和度之前检测错误条件。这是一个小的优化，因为错误条件通常更容易找到并且更重要。
USE方法可以发现可能成为系统瓶颈的问题，但不幸的是，系统可能同时存在多个问题。我们发现的问题可能并不是问题本身。
我们需要根据发现的问题做更多的发散。进一步的分析包括工作负载特征和深入分析。
一旦这些操作完成，我们应该有证据表明我们应该调整负载或资源本身。总结 USE 方法是一种简单的策略，我们可以使用它来对系统健康状况进行全面检查并识别常见的瓶颈和错误。
它可以在性能分析的早期进行并快速识别问题区域，在此基础上我们可以使用其他方法进行进一步的分析。 USE方法的优点是速度和可见性：通过考虑所有资源，我们不太可能错过检查项目；缺点是它只能发现某些类型的问题（瓶颈和错误）。
因此我们只能将其作为整体性能优化工具箱中的一种工具。 USE方法作为性能优化分析的起点，从使用情况、饱和度和错误情况的角度检查资源。
它的核心是让我们对系统有一个直观的认识和了解，而不是从一开始就使用一些工具来进行随机分析。目的捕捉。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-21
06-18
06-18
06-17
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用