Just a point TCPWindowsize parameter is measured in kilobytes not bytes. And according to Administrator's reference it must be between 0 and 2048. If not in range on client complains with ANS1036S for invalid value. On server values out of range mean 0, i.e. OS default. However this are side remarks. The main question is why client is idling. Have you monitored the node during to disk and to tape operation? Is migration starting during backup? Are you using DIRMC. You wrote client compression - what is the processor usage (user)? What is the disk load - is the processor I/O wait high? Is the paging space used - check with svmon -P. You should get much better results. For example recently we've achieved 500 GB in 3h10m - fairly good. It was similar to your config - AIX node&server, client compression, disk pool, GB ether. Ether was driven 10-25 MB/s depending on achieved compression. The bottleneck was EMC Symmetrix the node was reading from but another company was dealing with it and we were unable to get more than 60-70 MB/s read. Resourceutilization was set to 10.
Zlatko Krastev IT Consultant Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: Tuning TSM Zlatko: Here are the answers: > Have you tested what is the performance of FAStT 500 disks? > Those were > mid-class disk storage originally designed for PC servers > market and later > modified to be compatible with rs6k/pSeries. This is completely true: IBM installed FastT500 instead of SSA disks (they said they were faster). We have done a "re-cabling" of these devices, and got a better IO balance on the controllers. > Try some simple tests on the TSM server when quiet: > - 'date; dd if=/dev/zero of=/fastt_fs/test_file bs=262144 > count=16384; > date' to test write speed. Use large file to simulate TSM heavy load. > - 'date; dd if=/fastt_fs/test_file of=/dev/null' to check read speed In a test like you proposed, FastT500 brings a peformance of about 60MB/sec > Also check your Gb Ether - are you using Jumbo frames, have > you enabled in > AIX 'no -o rfc1323=1', what are send&receive bufsizes, what is > TCPWindowsize of TSM server&client. Have you measured > LAN&disk load during > backup? Yes, we're using this parameters: <from "no"> tcp_sendspace = 1048576 tcp_recvspace = 1048576 udp_sendspace = 64000 udp_recvspace = 64000 rfc1323 = 1 <from TSM server> TCPWindowsize 1310720 What I've observed is that during a client backup session, TSM seems to be idled for a long time (and the server machine has not constraint problems for memory or I/O) I can send other data. Thank you all. Ignacio > > Zlatko Krastev > IT Consultant > > > > Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > cc: > > Subject: Tuning TSM > > Hi: > I'm managing a pretty small TSM installation with 4 RS/6K machines (2 > 6M1 and 2 6H1) running AIX 4.3.3 (ML9). > TSM software consists of the server (running in a 6M1 - 7Gb RAM), and > the clients running in the same machine and on the others. > > I´ve got the following situation: > - the total of data backed up is about 200Gb's, > - 4 servers are connected using gigabit ethernet links (and > have 6Gb RAM > and 7Gb RAM each model 6H1 and 6M1 respectively) > - TSM uses a storage pool of 240Gb on FastT500 disks (those are > connected by FC channels) > - TSM uses a 3581 library (LTO) with 1 drive, > > The fact is (for the same set of information): > When I do an archive backup operation with TSM, the time > elapsed rounds > 5 hours (TSM writes "right to" the tape). > When I do an incremental backup operation, TSM uses about > 6:30hs for it > (TSM writes to storage pool). > > I'm looking for a rational approach to solve this "problem": isn't it > more fast writing to storage pool (disk) that to tape? > > Anyone had the same performance problem? > > Is it really a performance problem? > > I would like some commentaries about this, I can provide some > info about > the configuration of TSM and the AIX servers. > > Regards > > Ignacio >