微信号:dellemc_tech

介绍:为戴尔易安信客户提供技术支持服务,为广大IT行业用户分享技术文章与行业信息。

备份性能问题简单分析

2016-06-06 16:17 EMC中文技术社区

对于备份和恢复,除了关心数据是否真正能够被备份和恢复之外,我们也会比较关心它的速度,也就是所谓的性能,毕竟时间就是金钱嘛。况且不能数据都变化很多了,我们备份还一直在跑,这样也没有意义。

 

现在我就根据自己的经验来介绍一下可能会影响Avamar备份性能的因素,这样大家在以后的工作中遇到问题,可以简单的排查一下,从而有利于我们快速解决问题。

 

备份过程,简单来说就是客户端通过网络发送数据给Avamar服务器。

 

但是在这三部分,又有各种小的细节会影响备份速度。总体来说,影响备份性能的因素如下:

  1. cache文件不够大。

  2. 未被充分利用的CPU。

  3. 客户端和Avamar服务器之间连接过慢(网络方面)。

  4. 客户端磁盘性能不好(磁盘I/O)。

  5. 内存过低(<3gb)。

  6. Avamar服务器性能问题。

 

Avamar备份通常定义的标准速度是

  • 文件系统备份 = 大约一百万文件每小时

  • 数据库备份 = 大约100GB每小时


当然初次备份不算哦~~

 

下面我们来具体看一下:


  • cache文件不够大


首先请了解我们客户端主要有两种cache文件。f_cache主要用于文件系统备份,p_cache主要用于数据库类型备份。f_cache默认的总大小是物理RAM的1/8,p_cache是物理RAM的1/16。另外,cache文件的大小是成倍增长的,而不是一点一点增加。比如当前的cache文件大小是300MB的话,下一次增长它的大小就是600MB。

 

同时,我们都知道,Avamar是前端去重备份机制,它主要是基于cache文件来去重的。在之前“浅谈Avamar备份如何处理文件”这篇文章里面我们讲到备份开始的时候Avamar会对比本地文件和cache文件来决定哪些数据需要通过网络发送给Avamar服务器,哪些是已经备份过的数据,而不需要再次发送。

 

 

基于以上信息,如果默认的或者您限定的cache文件总的大小过小,从而导致它无法继续增长,备份速度就会受到很大影响。这时候我们就需要检查当前cache文件大小和它总的大小,决定是否更改其原来的值,从而改善备份速度。从备份日志里面,我们可以根据以下信息判断cache文件大小是否足够:


F_cache:

2014-02-04 06:34:37 avtar Warning <6562>: CAPACITY WARNING: The file cache is full; filecachemax=256MB, 2097150 entries overflowed.


P_cache;

<HASH_CACHE>entries=2097152,added=709614, overflow=56849</HASH_CACHE>

 

改变方法:登录到客户端,在c:\Program files\avs\var目录下,编辑或者创建avtar.cmd文件,添加以下参数:

--filecachemax=<size in MB> or <size in fraction>

--hashcachemax=<size in MB> or <size in fraction>

注意:cache文件大小不要超过物理RAM的1/4,因为这样也会影响性能。

 

  • 未被充分利用的CPU


例子:2013-02-07 08:12:59 avtar Info <8688>: Status 2013-02-07 08:12:59, 7,758,607 files, 156,089 folders, 380.4 GB (3,821,086 files, 128.5 GB, 33.80% new) 623MB  4% CPU  X:\images\IMAGES29\3704\

 

从上面备份结果我们看出备份过程CPU利用率只有4%。这种情况一般说明客户端比较忙(运行其他程序)或者磁盘性能有问题。

 

另外,一些第三方杀毒软件也会影响备份速度。

一般杀毒软件工作机制是如果有个程序打开某个文件,它就会去扫描一下这个文件以确保没有病毒。这种情况下,如果每个被备份的文件都被扫描,备份速度看起来就会很慢。所以,如果您需要备份某个客户端,请确保将avtar.exe加入到杀毒软件的安全列表中。

 

  • 客户端和Avamar服务器之间连接过慢(网络方面)


这种情况下,我们看到日志通常会有以下内容:

2013-03-08 02:33:20 avtar Info <8688>: Status 2013-03-08 02:33:20, 2,713 files, 695 folders, 1.198 GB (56 files, 809.2 KB, 0.06% new) 33MB   0% CPU  C:\Documents and Settings\cnwhite\ntuser.dat.LOG

2013-03-08 02:35:23 avtar Info <7694>: Server(mkeavbak05.mke.ra.rockwell.com) not responding (possible network congestion?) (600 seconds)

2013-03-08 02:39:39 avtar Info <7695>: Server(mkeavbak05.mke.ra.rockwell.com) is back (855 seconds)

2013-03-08 02:44:39 avtar Info <7694>: Server(mkeavbak05.mke.ra.rockwell.com) not responding (possible network congestion?) (300 seconds)

 

其实如果真的是网络问题所引起的性能缓慢,就已经不是我们Avamar技术支持人员要参与的操作了,但是为了帮助客户了解形势,我们一般也会帮助客户做一些基本测试(当然最好是能够有专门的网络工程师帮忙测试了^_^这需要客户的配合)。我们通常会使用iperf测试客户端和服务器之间的网络带宽。具体步骤如下:

  • 登录到客户端,打开putty并连接到Avamar  Server。

  • 然后在putty上面运行命令:iperf -s -i 1

  • 在命令运行的同时,也在客户端上面运行以下iperf命令:

  • iperf -c AvamarServerIP -i 1

  • 命令运行一段时间后中断操作然后查看结果。


我们也会运行备份测试,使用randchunk 参数来生成日志从而检测备份时使用的带宽:

avtar -c --randchunk=10000 --compress=none  --status=60  --comstats –nocache --logfile=c:\randchunk.log  --id=MCUser

--ap=MCUser1 --server=Avamar.emc.com --path=/clients/DaveTemplin.emc.com

 

如果是要测试网络延迟和丢包的话,可以使用常ping和tcpdump来检测。

 

  • 客户端磁盘性能不好(磁盘I/O)


其实,一般performance问题做下来,都是客户端磁盘性能不够好,但是一般客户最开始时候都不愿接受这种结果。所以我们通常会经过一系列的备份测试帮助客户去检查并了解情况,最终找到根本原因。

 

对于磁盘性能的测试,说实话,我们更希望客户自己能检查,毕竟我们在这方面的经验没有系统维护工程师或者存储管理员有经验丰富(囧)。但是我们还是会尽力滴,作为参考我们会采取以下措施去判断问题:

  1. 利用windows自带的performance测试工具performance monitor去观察磁盘性能。

  2. 手动从客户端复制文件到另外一个客户端看其花费的时间是否正常。

  3. 运行一个备份测试,加上—degenerate参数,例如:


avtar -c --degenerate --compress=none  --nocache --logfile=c:\degenerate.log

--id=MCUser  --ap=MCUser1 --server=Avamar.emc.com --path=/clients/DaveTemplin.emc.com  E:\testdata

有了这个参数,数据是不会真正通过网络被发送到Avamar服务器去的,这样我们可以通过备份速度来判断客户端这边是否有性能问题。

 

  • 内存过低(<3gb)


这个就是客户端系统资源的问题了。如果系统资源过少,Avamar运行时能用的memory就会很少从而影响备份速度。

 

  • Avamar服务器性能问题


这里也会涉及到很多,比如Avamar服务器很忙,某个节点的性能不好,gsan或者msc问题等等。

如果是这种情况的话,您所有的备份都可能会受到影响,或者至少大部分备份都会有问题,这时候,就放心交给我们来检查吧。

 

当然,我们也会单纯的从Avamar角度进行日志分析,然后大概判断问题所在。经典的做法就是:

  1. 登录到客户端,打开C:\Program Files\avs\var文件夹。

  2. 创建并编辑avtar.cmd文件,加入以下参数:

    --stats

    --status=60

    --comstats

  3. 保存此文件然后再次发起一个备份。等备份再次失败之后,收集日志并分析。

 

那么这些参数有什么用呢?

  • comstats 参数用于诊断avtar和gsan之间通信问题(每秒)

  • Avtar comstats 说明:

avtar Stats <0000>: 2013-10-11 06:18:20 COMSTATS:0 sent= 84 recv[0]= 84  pending= 1/ 5 int= 0/50 send= 0 bytes= 9408+ 17711 sleepms= 0 delay=(0.008 [0.000..0.210] sd=0.030 n= 53) (0.022 [0.000..0.324] sd=0.066 n= 31)

此条信息显示客户端数据发送量和服务器接受量,等待的数据量和数据延迟时间。通常我们会根据此信息判断是客户端数据发送不过来还是服务器太忙从而无法接受客户端发的数据,已经接收数据是否有延迟。

--status=60参数会每个60秒输出出来当前在备份哪个文件,目前为止扫描了多少文件,大小是多少,新增的数据量等等。

 

上面说了这么多,也不是说一有备份性能问题就由大家自己去检查,我们完全置身事外。只是希望在大家的配合下,我们能更快速有效的解决问题。

 

更具体的东西我就不介绍了,因为太深入或者太多的日志分析也会让大家觉得很烦。希望这些信息能给大家一个初步印象,那就是备份性能不是某一方面的因素决定的。

 

如果大家的工作中遇到任何问题,欢迎随时联系我们,一如既往,我们是很乐意和大家共同来处理分析并解决问题的。



更多精彩内容,请点击阅读原文”进行查看!

如何每天都能收到如此精彩的文章?

①点击右上角点击查看官方账号”→点击关注

②长按并识别下图中的二维码,直接访问EMC中文支持论坛


 
戴尔易安信技术支持 更多文章 VNX单块硬盘更换演示 VNX 25-Drive(磁盘驱动器)更换演示 VNX 15-Drive(磁盘驱动器)更换演示 Unity 2.5英寸磁盘驱动器更换演示 Unity 3.5英寸磁盘驱动器更换演示
猜您喜欢 推广小程序的这10个小窍门,你用了几个? Sublime Text 2 跨平台支持Win/Mac/Linux 硅谷海归打造中国“码云” 才云科技杭州盛放“码农”情怀 《我要上头条》第八期:《Python Web 开发实战》作者董伟明 .NET Core 现已支持DRPC,同时带来Apache Thrift