硬件监控系统(性能监控)

服务器层通常是来自多个供应商的各种硬件和开源软件。通常,很难解决服务器的底层性能问题,或者出于安全原因很难处理它们。即使碰巧发现了底层性能“事件”,也很少有传统的工具来衡量和分析硬件和软件的性能,而且往往是针对供应商的。因为真正的跨平台工具包很少存在,所以没有标准的方法来准确地查看事件、记录事件以供以后分析,或者有效地解决问题。

首先,跟踪延迟时间。

研究服务器环境性能的第一步是跟踪任何应用程序的事务延迟,从用户的请求事件到最终的屏幕绘制。下一步是绘制服务器的拓扑图。为了做到这一点,很多方面都会被质疑关于3360的**拓扑、数据库更新(锁)、磁盘阵列、进程调度、CPU性能、内存亲和力和驱动/中断服务时间。然后,使用一套性能分析工具沿着测量事务延迟的完整路径研究软件和硬件环境。用户交易的每一部分都应该能够显示所经历的延迟。性能工具应该衡量这些因素及其相关的性能退化。

一般需要详细研究与事务相关的用户线程,以及解决用户读写所需的路径。在调优系统延迟时间时,应该遵循两个步骤:首先,定义用户事务为满足用户请求而必须执行的每个步骤;然后计算每一步的时间。虽然这看起来很简单,但在多节点环境中可能相当困难。一个问题是找到一个准确的时间基准。

NTP(**时间协议)通常是本地机器中最好的定时方法,CPU的时基应该足够。每一步都必须尽可能准确地定义。每个步骤包括每个数据包的迁移,每个处理过的数据包的交换,每个磁盘设备的交互,每个**的交互。必须在每个步骤中记录时间戳,并保存以供分析。延迟研究中的这些时间戳将确定使用性能工具检查服务器环境的区域

两个。监视器的内容

我们必须决定在哪里监控什么,这可以从对系统事务延迟的研究中得到。我们还可以监控和分析服务于用户事务的每个组件,并尽快完成每个记录。最后是设备和工艺列表,然后一定要找到合适的方法来衡量有趣的内容。

简单来说,计算机有五种类型的可测量的感兴趣的数据对象用于性能分析:全局属性、CPU、**接口、磁盘和进程。前四个描述了用户的Unix计算机的物理属性。描述内存、分页和交换特征的全局属性;全局文件系统内存使用情况;以及其他项目,如时间、正常运行时间和平均负载。CPU类别包括中断、交叉调用、设备读/写、进程迁移等。**类别包括物理接口层及其组件,以及逻辑TCP/IP层,如套接字的使用。磁盘的类型包括物理磁盘设备、与CPU的互连、通道等。所有这些都是基于磁盘阵列的拓扑结构,从CPU的角度来看,它们通常是隐藏的。这四个类别描述了对硬件世界的看法。

最后一类是流程层,在这一层,大多数监控需求将首先被感受到。例如,用户可能会抱怨响应时间太慢。无论是CPU发热还是数据库运行速度比正常情况下慢,事件的第一点就是关注瓶颈进程。那么,问题就变成了在哪里发生了什么,如何记录了这些被耽搁的事件。

三个。工具盒选择的基础

常用的性能工具是有限的。例如,软件的大多数工程师都熟悉sar、vmstat、iostat和netstat,以及其他特定于供应商的工具。但是,一般来说,在并行和线程安全应用程序中,系统,了解系统的平稳响应时间需要比传统的工具集更全面的性能工具。

性能监控的首要问题是采样时间。大多数第三方工具收集服务器群的粗粒度性能数据,用于容量规划和服务器负载热点。在分布式环境中,测量应用程序性能的采样时间不同于容量规划所需的时间。成功的性能监控和分析需要细粒度的定时软件和硬件工具,这些很难找到。

那么问题就变成了什么是粗粒度,什么是细粒度?通常,粗粒度被定义为在5到30秒或更长时间内收集和存储的样本,而细粒度是指在百分之一秒到五秒内采样。对于担心交易延迟的软件工程师来说,一秒或更短的时间是必要的。这些系统可能每秒处理数万个事务,从分组输入到用户数据传输的延迟可能是10毫秒或更少。监视系统的唯一缺点是,如果决定以日志格式收集所有性能数据并将其存储在磁盘中,而监视系统可以支持如此细粒度的采样时间,则日志将非常大。

四个。服务器环境中的硬件问题集

有通用的问题集吗?它围绕着在可能位于存储区域**环境中的磁盘阵列上定义用户文件系统所涉及的硬件。服务器层有几个本地方法可以解决这个问题。最简单的形式是,文件系统被定义为跨越一个磁盘阵列的多个物理磁盘资产。从主机查看文件系统的磁盘有三种方式:从主机到磁盘阵列的互连;数组本身;并且磁盘作为物理单元呈现给主机系统。对于主机,我们可以看到物理元素,并将它们用作一组磁盘。这个元素通常是物理磁盘单元的路径,但是一些系统使用多路径驱动程序使问题复杂化。

大多数工具可以查看整个文件系统或单个磁盘,但很少有工具可以显示文件系统的性能以及用于构建文件系统的元素。这一点至关重要,因为整个链路的任何部分都可能出现性能下降。SAN环境中可能存在通道故障、降级或交换问题。根据问题的类型,任何元素都会受到不同的影响。

对于磁盘,最有用的指标是平均服务时间。路径中的间歇性故障可能是由SCSI连接器放错位置、扭曲的光缆或意外关闭的缓存引起的。它们通常表现为以服务时间衡量的长磁盘延迟。真正的问题是找到并隔离文件系统中执行不良的物理元素

造成延误的情况。

用户可以编写脚本来帮助提高中的性能

性能工具中定义磁盘单元**的能力。基本上,这些脚本允许对字节的读/写进行时间序列测量,并允许对元设备及其物理磁盘元素进行服务时间测量。进一步,用户可以选择一个盘片的所有单个元素,查看读/写和服务时间,并以时间序列格式显示数据,这样就可以轻松地发现性能异常,可以快速地将用户指向缓存阵列、通道、 SAN 环境、交换机、共享磁盘阵列资源等。此外,盘片集和元设备的定义可以允许用户对 CPU和**接口执行类似的操作。然后,用户可以在字段中捕获这样的事件,将其记录下来,并在 GUI 中读取日志,从而显示的服务器实时状态。

例如,在数据库延迟中,问题可能在用户的事务中,也可能是特定数据库交互不及时,或者特定的逻辑文件系统及其物理元素不能按要求执行。一个更全面的性能工具包应该可以找到有问题的硬件或阵列配置错误。

五、服务器环境中的进程问题

再以数据库更新线程为例,其中的数据库线程与其他几百个重量级和轻量级线程一起在实时数据库中运行。像许多应用程序一样,每个工作日都有大约一个活动高峰时段。线程检查数据库状态和传入数据,以便为服务器层上的其他数据库环境制定数据库更新。这个线程是数据库服务器上计算特定类别数据的几百个线程之一。这个线程中可能有三个生成更新的源,第一个更新源是当前的数据库状态;第二个来源是实时更新,通过一套前端计算机从外部来源接收的;第三个更新来源包括对若干用户事务处理机及其本地数据库的检查。

第一个关注点是在持续的峰值活动期间从这个线程的更新消费者之一注册的。当这个线程变慢时,用户数据库线程的性能会下降。虽然有几个数据库服务器,但只有启用这个流程的服务器存在性能问题,需要分析受影响服务器和未受影响服务器的磁盘阵列性能。

首先,检测磁盘阵列的统计数据,在性能较差的服务器上会存在更多的缓存损失。然后,研究接触该文件系统的线程的 i/o 速率。软件按照设计的方式运行,每次更新都会将体现到磁盘上。当系统变得繁忙时,检查活动增加,直到磁盘阵列缓存中有太多脏页。一旦磁盘阵列缓存被淹没,许多其他进程就会放慢速度。随着整个数据库环境的演变,全局数据库检查点和重新同步变得更加健壮,从而消除了应用程序中对本地每个进程进行检查的一些需求。

六、适用于所有服务器环境的工具包

一个功能全面的工具包必须满足工程师在当今操作的许多不同的环境。大多数商业安装通常是分离的子网,工程师与物理机器是分离的。甚至到现在,很少有工具能够提供保持所有这些机器正常运行所需的性能指标,也没有一套通用的工具来管理和排除多个云服务器的故障。

一般地,工具包中的主要组件是 CLI 风格的执行文件,它可以在任何服务器上远程运行。计算机的所有指标都被记录以便进行延迟分析。问题往往是在最意想不到的时候显现出来,随机的或者只有当某些条件得到满足的时候才显现出来。24小时不间断地在计算机前实时处理许多问题是不现实的。日志记录工具可以捕获系统崩溃,在特定时间进行调度,或者在满足某些用户设置的条件时对机器活动进行快照。这些日志可以被积累起来并在某个地方进行编排,以便支持重点分析。因此,所有参与者都可以对服务器事故的衡量标准有相同的看法。每个参与者都可以读取服务器事件的相同日志文件,能够从日志文件“播放”记录的服务器性能。故障排除程序可以暂停、回退、快进和循环日志中的区域,以便快速关注有问题的区域。

性能工具包的另一个组件应该是一个分析工具,帮助工程师在采样数据中找到与任何用户定义的基线不一致的东西。可以定义一个规则引擎,该引擎可以侦听计算机并在某些参数超出范围时报告。

七、小结

人工智能风格的分析将使我们更接近实时的确定问题,分析器应该能够检测硬件或软件与用户可设置阈值的差异,扫描进程数据,并确定导致事件的进程。例如,检测并扫描 I/O热点,以确定某些用户应用程序线程当时正在进行I/O活动。然后可以直接对那些执行I/O调用的线程执行操作,它应该是一个可以自动化的过程。工具包可以使用人工智能捕获软件定位事件并捕获关于事件的所有需要的数据。当我们使用这样一个高度可调的性能分析器来增加服务器的日志记录时,就将能够在正确的时间收集日志。

有了这种多平台互操作性,如果拥有了一组标准化的工具,才可以快速有效地解决性能问题。

作者丨半吊子全栈工匠

来源丨公众号:喔家ArchiSelf(ID:wireless_com)

dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

关注公众号【dbaplus社群】,获取更多原创技术文章和精选工具下载