一、环境是TSM Server 5.4 For Windows,以及TSM Client 5.2/5.4 For AIX,使用LAN backup。备份的速度比较正常,大概是20~30MB/s,恢复很慢,只有2MB/s。
网络和系统参数设置应该没什么问题,用ftp测试无论数据流往哪个方向都可以到达20MB/s以上。改了TSM Server/Client的几个和网络有关的参数,例如TCPBufSize以及TCPWindowSize,都没什么效果。
而且相同的设备,如果Server和Client都是相同平台,恢复速度也蛮正常。
有哪位兄弟碰到过这种情况?或者有谁给个解决问题的思路?
二、在client打开了-testflag=instrument :detail,在server端INSTrumentation Begin,两边得到的信息是一致的,就是网络传输慢。仔细分析其中的数据,凭经验隐约觉得和TCP窗口有关。看了TSM Client的TCPWindowSize是63KB,AIX 上的tcp_recvspace和tcp_sendspace都是16KB,理论上讲TSM的设置会覆盖AIX的系统设置。而且因为TSM的设置更大,所以传输性能应该更好才是。可是测下来TSM restore只有1~2MB/s,而FTP可以到达10MB/s以上,基本就是百兆网络的极限。
先不管了,把AIX的tcp_sendspace和tcp_recvspace都为512KB,rfc1323=1,测试TSM restore没用。根据TSM redbook的建议,把TSM client的TCPWindowSize也改为512KB,还是没用。感觉没辙的时候,尝试把TSM Server的TCPWindowSize也改为512KB,结果就好了。不过真是奇怪,redbook上说To improve restore performance, increase the TCPWINDOWSIZE on the client。再把AIX的tcp_sendspace和tcp_recvspace改回去,发现对性能没有影响。
PS:
1,开始时候的猜测是正确的,系统层面和网络层面的设置没有问题,问题出在TSM设置上
2,尽信书不如无书。
三、周二,去客户那做TSM恢复测试,环境是TSM Server 5.4.3.0 For Windows和TSM Client 5.2.0.0 For AIX,stgpool是DiskPool。测试时发现恢复速度很慢,只有2~3MB/s,但是备份的速度很快,超过20MB/s。首先怀疑是否是否网络有问题,但是用FTP测试发现双向传输数据都可以到20MB/s以上。由此排除了系统和网络的问题,把问题定位到TSM配置上。感觉上应该和TSM的网络参数设置有关,或者是TSM bug。Client是测试机,所以改了TCPWindowSize、TCPNoDelay和TCPBUFFSIZE,没有效果。因为TSM Server是生产机,没敢动。
周三,另搭了套测试环境,用我的笔记本做TSM Server,版本是5.4.0.2;找了台AIX做TSM Client,版本是5.4.0.0。测试重现了周二的现象,所以和TSM Client版本应该没啥关系。然后想想,恢复的流程包括TSM Server从stgpool中读取数据,通过网络传输到Client,TSM Client将数据写入磁盘。三个环节中任何一个环节出问题都有可能。于是另找台AIX机器安装TSM Server5.4.0.0,然后两台AIX机器之间做TSM恢复是正常的,排除了TSM Client的问题。感觉问题出在TSM Server上,是bug或者配置有问题。看了TSM5.5 performance tunning guide,它建议的几个参数值,例如BUFFERPOOLSIZE、LOGPOOLSIZE以及TCPWINDOWSIZE都没问题。前2个参数和 TSM DB性能有关,最后一个参数十分有嫌疑,但是redbook上说"To improve backup performance, increase the TCPWINDOWSIZE on the server. To improve restore performance, increase the TCPWINDOWSIZE on the client."我将Client的TCPWINDOWSIZE提高到512KB,仍然没用,至此感觉没了方向,只能把测试环境恢复到最初情况。晚上回家后发帖求助,钱老大建议在client打开-testflag=instrument:detail。对这个东西,到网上找了些资料,感觉应该有帮助。
周四,再次做恢复测试。在client用-testflag=instrument:detail,在server端用INSTrumentation Begin。然后比较生成的文件。先看server端的输出,简化下输出结果:
Thread 37 SsAuxSrcThread (Win Thread ID 2828) 13:28:29.484-->13:29:40.687
Operation Count Tottime Avgtime Mintime Maxtime InstTput Total KB
----------------------------------------------------------------------------
Disk Read 379 1.622 0.004 0.000 0.172 59817.5 97024
Thread 34 SessionThread (Win Thread ID 3996) 13:28:29.484-->13:29:40.687
Operation Count Tottime Avgtime Mintime Maxtime InstTput Total KB
----------------------------------------------------------------------------
Network Send 759 71.091 0.094 0.000 0.234 1364.4 96998
看上去读很正常,瓶颈在网络传输上。另外97024/379=256KB,96998/759=128K。因为TCP其实是字节流,所以这个128KB应该是应用层的缓冲区大小,也就是调用1次read从stgpool读取256KB数据,然后分2次调用write发送数据,每次发送128KB。
再看server的输出,简化下
File I/O 3.040 5.6 544
Data Verb 94.816 173.0 548
......
Total number of bytes transferred: 135.59 MB
LanFree data bytes: 0 B
Server-Free data bytes: 0 B
Data transfer time: 94.79 sec
Network data transfer rate: 1,464.65 KB/sec
Aggregate data transfer rate: 1,387.21 KB/sec
看上去写文件也正常,另外135.6MB/548=256KB。也就是调用1次read从网络读取256KB数据,然后调用1次write将数据写入磁盘。
从输出看,应用以128/256KB作为缓冲区发送接收数据,但是TSM层面的TCPWINDOWSIZE是63KB,TSM Client系统层面的tcp_sendspace以及tcp_recvspace都是16KB。感觉似乎有点不匹配。不过这个几个测试让我很困惑:
FTP测试表明双向传输都正常,说明tcp_sendspace以及tcp_recvspace应该没关系。
redbook说提高恢复性能要增加TSM Client的TCPWINDOWSIZE,这个说法和网络理论也是一致的。
但是增大TSM Client的TCPWINDOWSIZE没有提高恢复速度
从头开始测试:
将TSM Client的tcp_sendspace以及tcp_recvspace调整为63KB,没有效果。
将TSM Client的TCPWINDOWSIZE调整为512KB,将TSM Client的tcp_sendspace以及tcp_recvspace调整为512KB,rfc1323=1,sb_max调整为10MB,没有效果
TSM Client的网络参数都调整过了,没辙了。现在只能怀疑理论上最不可能的TSM Server的TCPWINDOWSIZE了。原本想看看WINDOWS上类似tcp_sendspace以及tcp_recvspace的值,不过不知道该怎么看。
把TSM Server的TCPWINDOWSIZE调整为512KB,测试,结果就好了。把TSM Client的tcp_sendspace以及tcp_recvspace改回去,也是可以的。说明就是TSM Server的TCPWINDOWSIZE参数设置不对。
今天修改了生产环境中TSM Server的TCPWINDOWSIZE参数,做恢复测试也正常。虽然这个问题是解决了,但是总觉得不够彻底。从redbook看接收数据的那一方的 TCPWINDOWSIZE参数对数据传输有影响,而实际情况却相反。TSM Server的TCPWINDOWSIZE参数对backup没有影响,对restore反而有影响。另外两台AIX小型机之间作TSM恢复是正常的,TSM Server参数也没调整过
收起