一个tsm性能调优的案例，欢迎各位请借鉴
一、环境是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参数也没调整过
网络和系统参数设置应该没什么问题，用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参数也没调整过