Re: DB2 high speed SP switch backups dead slow
** High Priority ** Hi Travis, bunch of thanks for ur kind responce .Yesterday changed couple of parameter in sys file at client and I could finish my backup 3 hrs which is 14 before.i could'nt belive that. still I need tune few things in tcp/ip and high speed switch. thanks again. best regards /muthyam >>> Travis Zong <[EMAIL PROTECTED]> 09/15/03 11:22AM >>> Muthyam, We got the same problem since our TSM migrated to 5.1.5. After one month's work, I made the following changes on TSM DB2 Client, and fixed the problem. I think TCPWINDOWSIZE is the critical factor. Both server and clients were 2048 in our environment. Good luck!! Travis FROM: LARGECOMMBUFFERSYES TCPWINDOWSIZE 2048 TCPBUFFSIZE 64 TO: LARGECOMMBUFFERSNO TCPWINDOWSIZE 128 TCPBUFFSIZE 32 TCPNODELAY YES This electronic mail transmission contains information from Joy Mining Machinery which is confidential, and is intended only for the use of the proper addressee. If you are not the intended recipient, please notify us immediately at the return address on this transmission, or by telephone at (724) 779-4500, and delete this message and any attachments from your system. Unauthorized use, copying, disclosing, distributing, or taking any action in reliance on the contents of this transmission is strictly prohibited and may be unlawful. <>
Re: DB2 high speed SP switch backups dead slow.
Long, long time ago, in ancient Rome there was a sentence - "divide and conquer". Unfortunately I did not see this aproach used while it helps most of the time. Why not to isolate each part of the data route and ensure it is working at best possible throughput? This might help to identify the bottleneck. The subject is stating the "SP switch" backups are slow but are they due to switch problems or for other reason(s)?!? 1. What is the speed when DB2 backup is performed to a file within the same system? If its is good proceed with next, if not - investigate. Information to be considered: - number of disks (Shark is Shark, but how many ranks are used for DB and what nodes/applications are accessing the same rank) - number of tablespaces, managed by system or managed by database - tablespace(s) page size - what is the load on the DB2 during backup (the SP is not bought for nothing) - what is the load on the processors, HBAs and hdisks/vpaths before and during backup 2. Number one advice when network problems are suspected - run FTP and measure the performance. If the FTP is performing fine (this is a SP switch on the end, it ought to achieve about 95-100 MB/s) stop blaming the network. If FTP is slow, the TSM will also be slow without any fault on its side - investigate the switch or TCP/IP stack. 3. Check for IP addressing problems (apologies if sounds silly or offending) - if TCPServeraddress points to Ethernet address instead of css0 address, obviously the speed would be lower by an order. BTW: Miles, in your example TCPS=127.0.0.1 and switch is not used at all, so the example does not relate to "switch" problem of the subject. 4. Check the speed of a backup performed by a client running on same system as TSM server - will drop the network from the equation. If performance is poor, the TSM server has to be tuned. If performance is good - investigate other parts. Zlatko Krastev IT Consultant Muthyam Reddy <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 10.09.2003 22:18 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject:DB2 high speed SP switch backups dead slow. ** High Priority ** Hi TSMers, I hope someone got experiance on same before . This is problem about db2(7.1) backups on high speed switch to TSM .Present we are taking 430Gb of data to tsm which is taking 14 hrs to finish.recently I have changed couple of paramters on 'css' and 'no' to improve performance based on IBM docs.Still my backups takes same time. no doubt I missed some parts on TSM/AIX/db2 to lubricate. Please can any one dump some ideas to fix this this and how long its taking in ur environment same setup. We are using four session on db2(7.1) and copying to tape pools directly. please send ur back times with same environments. please send me some tips to make my backups fast. please write if wants information. thanks and regards muthyam
Re: DB2 high speed SP switch backups dead slow.
Some things to try: 1. verify that the MTU is consistent for all nodes, from your cws: [EMAIL PROTECTED]:/>dsh "netstat -i | grep css0" unxa_sp: css0 65504 link#4 3496790 0 4212524 0 0 unxa_sp: css0 65504 192.168.17 unxa_sw3496790 0 4212524 0 0 unxb_sp: css0 65504 link#4 3500733 0 3392237 0 0 unxb_sp: css0 65504 192.168.17 unxb_sw3500733 0 3392237 0 0 unxc_sp: css0 65504 link#3 3435131 0 3620093 0 0 unxc_sp: css0 65504 192.168.17 unxc_sw3435131 0 3620093 0 0 unxm_sp: css0 65504 link#5 3486660 0 5827317 0 0 unxm_sp: css0 65504 192.168.17 unxm_sw3486660 0 5827317 0 0 unxp_sp: css0 65504 link#521731474 0 30705999 0 0 unxp_sp: css0 65504 192.168.17 unxp_sw 21731474 0 30705999 0 0 unxr_sp: css0 65504 link#682760978 0 79211973 0 0 unxr_sp: css0 65504 192.168.17 unxr_sw 82760978 0 79211973 0 0 Yours should be: 65520. 2. my dsmserv.opt TCPWINDOWSIZE 2048 BUFPoolsize 262144 3. client dsm.sys settings: unxr:/usr/tivoli/tsm/client/ba/bin>cat dsm.sys Servername unxr NODENAME unxr TCPPort 1500 SHMPort 1510 TCPServeraddress 127.0.0.1 tcpb 64 tcpwindowsize2048 tcpnodelay Yes TXNbytelimit 2097152 resourceutilization 10 passwordaccess generate LARGECOMMBUFFERS No 4. are you sure you want client compression? 5. And again, try and identify the bottleneck. Miles >>> "Muthyam Reddy" <[EMAIL PROTECTED]> 11-Sep-03 10:13:50 AM >>> ** High Priority ** thanks a lot for quick responce. we have AIX:4.3.3.0 PSSP version:3.1.1.0 OS kernel:64bit in all SP nodes TSM Tapedrives:IBM 3590 Tape Drive and Medium Changer. I have set css0 spoolsize,rpoolsize to 16777216 in both client and server. TSM server type:S80, 7017 SP switch css0 type:SP Switch Communications Adapter (Type 6-F) TSM software level:5.1.5.0 in both client and server. all out nodes are hoocked to SHARK disk storage.those SSA drives. dsm.sys parametrs at client. tcpnodelay yes compression yes LARGECOMMBUFFERS NO TCPwindow 2048 TCPbuffsize 256 TCPNodelayyes PASSWORDACCESS generate resourceutilization 8 thanks and regards muthyam >>> "Miles Purdy" <[EMAIL PROTECTED]> 09/10/03 03:47PM >>> That seems terribly slow. 430 GB in 14 hours is only 8.7 MB/s aggregate throughput. Over four streams that's only 2 MB/s/stream. It has been my experience that the source hdisks are usually the bottleneck. There are only two tunables for the switch adapter, rpoolsize and spoolsize. These can be changed, for example: chdev -l css0 -a spoolsize=14680064 chdev -l css0 -a rpoolsize=16777216 A couple of things that come to mind: - are you mixing machines with 32 and 64 bit kernels on the same SP Switch? - what version of AIX are you running? What version of PSSP? What tape drives do you have? - what are your vmtune settings? - where is the bottleneck? - is the switch performing well? - check the source disks - check the VMM >>> [EMAIL PROTECTED] 10-Sep-03 2:18:05 PM >>> ** High Priority ** Hi TSMers, I hope someone got experiance on same before . This is problem about db2(7.1) backups on high speed switch to TSM .Present we are taking 430Gb of data to tsm which is taking 14 hrs to finish.recently I have changed couple of paramters on 'css' and 'no' to improve performance based on IBM docs.Still my backups takes same time. no doubt I missed some parts on TSM/AIX/db2 to lubricate. Please can any one dump some ideas to fix this this and how long its taking in ur environment same setup. We are using four session on db2(7.1) and copying to tape pools directly. please send ur back times with same environments. please send me some tips to make my backups fast. please write if wants information. thanks and regards muthyam This electronic mail transmission contains information from Joy Mining Machinery which is confidential, and is intended only for the use of the proper addressee. If you are not the intended recipient, please notify us immediately at the return address on this transmission, or by telephone at (724) 779-4500, and delete this message and any attachments from your system. Unauthorized use, copying, disclosing, distributing, or taking any action in reliance on the contents of this transmission is strictly prohibited and may be unlawful. <>
Re: DB2 high speed SP switch backups dead slow.
try: on TSM compressionno TCPwindow 128 or 256 TCPbuffsize 32 on aix try to enable tcp_nodelayack. this is APAR IY31983. Cordiali saluti Gianluca Mariani Tivoli TSM Global Response Team, Roma Via Sciangai 53, Roma phones : +39(0)659664598 +393351270554 (mobile) [EMAIL PROTECTED] The Hitch Hiker's Guide to the Galaxy says of the Sirius Cybernetics Corporation product that "it is very easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all. In other words ? and this is the rock solid principle on which the whole of the Corporation's Galaxy-wide success is founded -their fundamental design flaws are completely hidden by their superficial design flaws"... Muthyam Reddy <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: "ADSM: cc: Dist Stor Subject: Re: DB2 high speed SP switch backups dead slow. Manager" <[EMAIL PROTECTED] .EDU> 11/09/2003 17:13 Please respond to "ADSM: Dist Stor Manager" ** High Priority ** thanks a lot for quick responce. we have AIX:4.3.3.0 PSSP version:3.1.1.0 OS kernel:64bit in all SP nodes TSM Tapedrives:IBM 3590 Tape Drive and Medium Changer. I have set css0 spoolsize,rpoolsize to 16777216 in both client and server. TSM server type:S80, 7017 SP switch css0 type:SP Switch Communications Adapter (Type 6-F) TSM software level:5.1.5.0 in both client and server. all out nodes are hoocked to SHARK disk storage.those SSA drives. dsm.sys parametrs at client. tcpnodelay yes compression yes LARGECOMMBUFFERS NO TCPwindow 2048 TCPbuffsize 256 TCPNodelayyes PASSWORDACCESS generate resourceutilization 8 thanks and regards muthyam >>> "Miles Purdy" <[EMAIL PROTECTED]> 09/10/03 03:47PM >>> That seems terribly slow. 430 GB in 14 hours is only 8.7 MB/s aggregate throughput. Over four streams that's only 2 MB/s/stream. It has been my experience that the source hdisks are usually the bottleneck. There are only two tunables for the switch adapter, rpoolsize and spoolsize. These can be changed, for example: chdev -l css0 -a spoolsize=14680064 chdev -l css0 -a rpoolsize=16777216 A couple of things that come to mind: - are you mixing machines with 32 and 64 bit kernels on the same SP Switch? - what version of AIX are you running? What version of PSSP? What tape drives do you have? - what are your vmtune settings? - where is the bottleneck? - is the switch performing well? - check the source disks - check the VMM >>> [EMAIL PROTECTED] 10-Sep-03 2:18:05 PM >>> ** High Priority ** Hi TSMers, I hope someone got experiance on same before . This is problem about db2(7.1) backups on high speed switch to TSM .Present we are taking 430Gb of data to tsm which is taking 14 hrs to finish.recently I have changed couple of paramters on 'css' and 'no' to improve performance based on IBM docs.Still my b
Re: DB2 high speed SP switch backups dead slow.
** High Priority ** thanks a lot for quick responce. we have AIX:4.3.3.0 PSSP version:3.1.1.0 OS kernel:64bit in all SP nodes TSM Tapedrives:IBM 3590 Tape Drive and Medium Changer. I have set css0 spoolsize,rpoolsize to 16777216 in both client and server. TSM server type:S80, 7017 SP switch css0 type:SP Switch Communications Adapter (Type 6-F) TSM software level:5.1.5.0 in both client and server. all out nodes are hoocked to SHARK disk storage.those SSA drives. dsm.sys parametrs at client. tcpnodelay yes compression yes LARGECOMMBUFFERS NO TCPwindow 2048 TCPbuffsize 256 TCPNodelayyes PASSWORDACCESS generate resourceutilization 8 thanks and regards muthyam >>> "Miles Purdy" <[EMAIL PROTECTED]> 09/10/03 03:47PM >>> That seems terribly slow. 430 GB in 14 hours is only 8.7 MB/s aggregate throughput. Over four streams that's only 2 MB/s/stream. It has been my experience that the source hdisks are usually the bottleneck. There are only two tunables for the switch adapter, rpoolsize and spoolsize. These can be changed, for example: chdev -l css0 -a spoolsize=14680064 chdev -l css0 -a rpoolsize=16777216 A couple of things that come to mind: - are you mixing machines with 32 and 64 bit kernels on the same SP Switch? - what version of AIX are you running? What version of PSSP? What tape drives do you have? - what are your vmtune settings? - where is the bottleneck? - is the switch performing well? - check the source disks - check the VMM >>> [EMAIL PROTECTED] 10-Sep-03 2:18:05 PM >>> ** High Priority ** Hi TSMers, I hope someone got experiance on same before . This is problem about db2(7.1) backups on high speed switch to TSM .Present we are taking 430Gb of data to tsm which is taking 14 hrs to finish.recently I have changed couple of paramters on 'css' and 'no' to improve performance based on IBM docs.Still my backups takes same time. no doubt I missed some parts on TSM/AIX/db2 to lubricate. Please can any one dump some ideas to fix this this and how long its taking in ur environment same setup. We are using four session on db2(7.1) and copying to tape pools directly. please send ur back times with same environments. please send me some tips to make my backups fast. please write if wants information. thanks and regards muthyam This electronic mail transmission contains information from Joy Mining Machinery which is confidential, and is intended only for the use of the proper addressee. If you are not the intended recipient, please notify us immediately at the return address on this transmission, or by telephone at (724) 779-4500, and delete this message and any attachments from your system. Unauthorized use, copying, disclosing, distributing, or taking any action in reliance on the contents of this transmission is strictly prohibited and may be unlawful. <>
Re: DB2 high speed SP switch backups dead slow.
Also, please reply with the following information: dsm.sys contents TSM software levels. Which type of switch? Is it the one that is 150MB/sec? What is your TSM server machine type? At 02:47 PM 9/10/2003 -0500, you wrote: That seems terribly slow. 430 GB in 14 hours is only 8.7 MB/s aggregate throughput. Over four streams that's only 2 MB/s/stream. It has been my experience that the source hdisks are usually the bottleneck. There are only two tunables for the switch adapter, rpoolsize and spoolsize. These can be changed, for example: chdev -l css0 -a spoolsize=14680064 chdev -l css0 -a rpoolsize=16777216 A couple of things that come to mind: - are you mixing machines with 32 and 64 bit kernels on the same SP Switch? - what version of AIX are you running? What version of PSSP? What tape drives do you have? - what are your vmtune settings? - where is the bottleneck? - is the switch performing well? - check the source disks - check the VMM >>> [EMAIL PROTECTED] 10-Sep-03 2:18:05 PM >>> ** High Priority ** Hi TSMers, I hope someone got experiance on same before . This is problem about db2(7.1) backups on high speed switch to TSM .Present we are taking 430Gb of data to tsm which is taking 14 hrs to finish.recently I have changed couple of paramters on 'css' and 'no' to improve performance based on IBM docs.Still my backups takes same time. no doubt I missed some parts on TSM/AIX/db2 to lubricate. Please can any one dump some ideas to fix this this and how long its taking in ur environment same setup. We are using four session on db2(7.1) and copying to tape pools directly. please send ur back times with same environments. please send me some tips to make my backups fast. please write if wants information. thanks and regards muthyam This electronic mail transmission contains information from Joy Mining Machinery which is confidential, and is intended only for the use of the proper addressee. If you are not the intended recipient, please notify us immediately at the return address on this transmission, or by telephone at (724) 779-4500, and delete this message and any attachments from your system. Unauthorized use, copying, disclosing, distributing, or taking any action in reliance on the contents of this transmission is strictly prohibited and may be unlawful. <> Dave Canan TSM Performance IBM Advanced Technical Support [EMAIL PROTECTED]
Re: DB2 high speed SP switch backups dead slow.
That seems terribly slow. 430 GB in 14 hours is only 8.7 MB/s aggregate throughput. Over four streams that's only 2 MB/s/stream. It has been my experience that the source hdisks are usually the bottleneck. There are only two tunables for the switch adapter, rpoolsize and spoolsize. These can be changed, for example: chdev -l css0 -a spoolsize=14680064 chdev -l css0 -a rpoolsize=16777216 A couple of things that come to mind: - are you mixing machines with 32 and 64 bit kernels on the same SP Switch? - what version of AIX are you running? What version of PSSP? What tape drives do you have? - what are your vmtune settings? - where is the bottleneck? - is the switch performing well? - check the source disks - check the VMM >>> [EMAIL PROTECTED] 10-Sep-03 2:18:05 PM >>> ** High Priority ** Hi TSMers, I hope someone got experiance on same before . This is problem about db2(7.1) backups on high speed switch to TSM .Present we are taking 430Gb of data to tsm which is taking 14 hrs to finish.recently I have changed couple of paramters on 'css' and 'no' to improve performance based on IBM docs.Still my backups takes same time. no doubt I missed some parts on TSM/AIX/db2 to lubricate. Please can any one dump some ideas to fix this this and how long its taking in ur environment same setup. We are using four session on db2(7.1) and copying to tape pools directly. please send ur back times with same environments. please send me some tips to make my backups fast. please write if wants information. thanks and regards muthyam This electronic mail transmission contains information from Joy Mining Machinery which is confidential, and is intended only for the use of the proper addressee. If you are not the intended recipient, please notify us immediately at the return address on this transmission, or by telephone at (724) 779-4500, and delete this message and any attachments from your system. Unauthorized use, copying, disclosing, distributing, or taking any action in reliance on the contents of this transmission is strictly prohibited and may be unlawful. <>
