作为Avamar管理员,我们有时候会遇到这样的问题为什么Avamar有对文件系统的备份有时快有时慢,或者为什么同样大小的文件系统在某些主机上花费了更长的备份时间。我们知道,制约备份性能的因素有很多,例如,磁盘性能,CPU使用率、网络带宽以及文件系统的数据变化量。在工作中,我们也接到过很多关于备份性能的case,可以说大部分都是由于客户环境问题造成的。这篇文章主要介绍如何使用PerfMon,从磁盘性能和CPU使用率方面来诊断制约Avamar备份性能的原因。

         Windows PerfMon的全称是Windows Performance Monitor,是一个强大的性能诊断工具,其中可监控的条目包括CPU,内存,磁盘,应用程序等等。这里我们只关注与存储相关的Physical Disk和与CPU相关的Processor中的性能条目,深入介绍每个条目的含义。因为磁盘系统负责存储和处理主机上的数据和程序,而CPU的使用率决定了有多少可用资源可分配给avtar,磁盘和CPU的性能瓶颈会对备份速度产生极大的影响。

   使用PerfMon:

      打开PerfMon的方法很简单,在Windows桌面直接点击开始 运行 输入PerfMon。打开工具以后,从左侧选项栏选择Performance Monitor。点击右侧窗口上的绿色添加按钮,添加性能条目。在Available Counters处选择Physical Disk然后展开,Instance of Selected Object选择所需要查看的磁盘,点击Add。在截图中,我们添加了所有的物理磁盘性能指标。

1.png

       选择需要的性能指标和监控的磁盘以后,点击OKPerfMon开始对磁盘性能数据进行监控与采样。PerfMon为用户提供了三种不同的呈现方式:趋势图、柱状图和报表。实际上,图像的呈现方式对Avamar管理员来说并不重要,我们最需要关注的是图像下方Average栏提供的数据,如图:

 

2.png

          Physical Disk

从图中我们可以看出, Physical Disk中的性能条目包含:

5.png

    虽然Physical Disk所涉及的条目/指标众多,但是实际上,很多指标都是用不同的计算方法表示相同的概念。下面我们把这些性能条目按照存储系统中常用的性能指标Disk Response TimeDisk Queue Length进行分类,这样更加容易理解和区分。

       关于磁盘响应时间(Disk Response Time)条目:

  1. Avg. Disk sec/Transfer:显示了存储端处理的每个IO的平均时间。

  2. Avg. Disk sec/Read:显示了存储端处理的每个读IO的平均时间。

       3. Avg. Disk sec/Write:显示了存储端处理的每个写IO的平均时间。

    上述条目显示的单位都是毫秒ms。这些条目是需要在性能分析中最先查看的内容,Disk Response Time直接决定了存储系统对应用的服务水平,包括Avamar。通常用户感觉到性能问题,也是因为磁盘系统的Disk Response Time上升。下面以文件系统和数据库应用为例,给出一些Disk Response Time的阀值,如果磁盘响应在对应的范围内,则视为可以接受,否则需要进一步查看原因。当然根据生产环境的不同和应用的状况也需要区别对待。

     文件系统:

  • 0-10,比较理想
  • 0-20ms,可接受范围。
  • >20ms,会有性能问题,需要解决方案。

    数据库 (Exchange and SQL)

  • 0-10ms,可接受范围。
  • >10ms,需要优化。

       从下图我们可以看出,在空闲状态下Avg. Disk sec/Transfer的数值仅为0.004ms

3.png

关于队列长度(Disk Queue Length)的条目:

    1. Avg. Disk Queue Length:显示了当前磁盘队列长度,也就是有多少个IO在等待存储来处理。

    2. Avg. Disk Read Queue Length:显示了存储操作正在等待被存储做读处理的请求数目。

    3. Avg. Disk Write Queue Length:显示了存储操作正在等待被存储做写处理的请求数目。

           这几个值显示了磁盘队列长度的相关信息。所谓Disk Queue也就是服务器端 (主机) 发出的存储操作正在等待被存储处理的请求数目。这个条目也与Avamar的备份性能高度相关。举个例子,Avamar发出一条读请求,但是目标磁盘当时正在处理其他任务。那么这个新的读请求就会被放在磁盘队列里。这时候磁盘队列的值就是1。理论上讲,Avg. Disk Queue Length的值不应该大于1,如果看到采样期间,平均的Queue Length大于1,则说明在采样的某段时间存储无法完全响应应用端(Avamar)所发出的IO请求,也就是说在这段时间里,Avamar无法进行备份或者备份很慢。

  其他需要关注的性能条目:

       % idle time这个条目准确记录了磁盘在多少时间下保持在空闲状态。如果此数值低于20%,说明磁盘系统处于极度繁忙(饱和)状态。如果磁盘系统长期处于饱和状态,您可以考虑采用更快的磁盘系统取代现有的。

Processor

       我们用同样的方法,把Processor的性能条目添加到监控中,如图:

4.png

      在这诸多条目中,可能会影响Avamar备份性能的是% Processor TimeProcessor Queue Length

   1. % Processor Time:显示了处理器执行一个非空闲线程所花时间的百分比。如果这个数值大于85,则说明当前处理器过度使用。这种情况就可能导致avtarAvamar用来执行备份和恢复的进程)不能被分配到足够的CPU资源来进行备份工作。

       2. Processor Queue Length:显示了当前处理器队列中的线程数。如果在一段时间内,次数值两倍于CPU的数量,则说明CPU没有足够的处理能力。这时,主机可能就需要一个更快的处理器了。

 

Roy Tian

Avamar技术支持工程

Data Protection and Availability Solution

EMC客户服务