Re: Ang: tdp for domino LAN free backup poor performance
Hi Daniel TDP through LAN takes 38 hours and LANfree takes 30 hours. I am also working on the OS/HARdware performance factor, I am too having doubt that the read I/O is slow... We are having HP server ProLiant DL180 G6 , windows 2003 64Bit , OS WIN2k3 64_bit Ent Ed. Lotus. 8.5.2 TDP for mail 5.5.3 Storage agent 5.5 Version of ibmtape device driver on the Domino windows host that controls tape drives---6.2.1.5 Regards Sandeep - Original Message - From: Daniel Sparrman daniel.sparr...@exist.se To: ADSM-L@vm.marist.edu Sent: Wednesday, May 18, 2011 10:20 AM Subject: [ADSM-L] Ang: tdp for domino LAN free backup poor performance Hi First off, there are several things that affect the performance except for just the optfile, software versions and your operating system: * What speed are you having making the backup over the LAN? * How fast are the disks on your Domino server, are they able to transfer data at the speeds your tape drives are writing? * How large are the files on your Domino server (average) ? * What's the version of the IBMtape driver on your Domino host? The version on your TSM server (which controls the library) really doesnt affect read/write performance since it only controls the robotics. Have you verified that the backup is actually being done across the SAN and not the LAN? 700GB in 30 hours is 23MB/s, which more looks like a slower than average LAN backup over gigabit ethernet. If your Domino server cant deliver data to the tapes drives with enough speed, you'll end up with a shoeshine effect, which will seriously reduce performance. Since you're using IBMtape, I'm assuming you're using some sort of LTO drives. If you for example have a LTO3 drive, it will write data @ 80MB/s natively. If your host only delivers data at 40MB/s, you will have a drive that is spending more time rewinding than actually writing the data. Some more information about your environment (hardware on both client server incl tape technology, your TDP configuration file) would be helpful in determining the error. Best Regards Daniel Sparrman Exist i Stockholm AB Växel: 08-754 98 00 Fax: 08-754 97 30 daniel.sparr...@exist.se http://www.existgruppen.se Posthusgatan 1 761 30 NORRTÄLJE -ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU skrev: - Till: ADSM-L@VM.MARIST.EDU Från: Sandeep Jain sandeep.j...@dcmds.com Sänt av: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Datum: 05/18/2011 06:54 Ärende: tdp for domino LAN free backup poor performance HI friends i am experiencing very very poor backup performance while taking backup of domino server. It is having around 700GB of data and LAN FREE backup on 2 tapes completing in 30 hours. OS WIN2k3 64_bit Ent Ed. Lotus. 8.5.2 TDP for mail 5.5.3 Storage agent 5.5 Version of ibmtape device driver on the Domino windows host that controls tape drives---6.2.1.5 i have also tried performance tunning parameters but no luck. DOMTXNGROUPMAX= 64 DOMTXNBYTELIMIT =2097152 dsm.opt *==* * * * IBM Tivoli Storage Manager for Mail * * Data Protection for Lotus Domino * * * * Sample Options File * * * *==* COMMMethod TCPip TCPPort 1500 TCPServeraddress 10.3.3.34 TCPWindowsize 63 TCPBuffSize 32 TXNBYTELIMIT 2097152 #12288; NODename domino_PDCHM_tdp PASSWORDAccess Generate #12288; SCHEDMODE Polling *SCHEDLOGRetention 14 *SCHEDMODE Prompted *TCPCLIENTADDRESS yy.yy.yy.yy *TCPCLIENTPORT 1502 enablelanfree yes *lanfreecommmethod tcpip *lanfreetcpport 1500 #12288; COMPRESSIon NO COMPRESSAlways NO #12288; #12288; * Exclude all databases named db1.nsf regardless of where they appear *EXCLUDE db1.nsf * Exclude all databases that match help5_* in the help subdirectory *EXCLUDE help\help5_* * Include all databases in the mail6 directory *INCLUDE mail6\...\* * Assign all databases that match *.nsf in the mail subdirectory * to the MAILDB management class *INCLUDE mail\*.nsf* MAILDB * Exclude all databases in the mail6 subdirectory from compression *EXCLUDE.COMPRESSION mail6\...\* * Encrypt all databases in the mail5 directory *INCLUDE.ENCRYPT mail5\...\* * The Default include/exclude list follows: * * Note: You can back up the log.nsf database but you can only restore * it to an alternate name. * EXCLUDE log.nsf EXCLUDE mail.box * Include all transaction logs INCLUDE S*.TXN TCPNODELAY YES Regards Sandeep jain -- I am using the free version of SPAMfighter. We are a community of 7 million users fighting spam. SPAMfighter has removed 18254 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len The Professional version does not have this message Disclaimer: This e-mail is intended for the sole use of the recipient(s) and may contain confidential or privileged information. If you are not the intended recipient
Re: Ang: tdp for domino LAN free backup poor performance
Unsubscribe Regards Oni Abayomi This email and any attachments are confidential and may also be privileged. If you are not the addressee, do not disclose, copy, circulate or in any other way use or rely on the information contained in this email or any attachments. If received in error, notify the sender immediately and delete this email and any attachments from your system. Emails cannot be guaranteed to be secure or error free as the message and any attachments could be intercepted, corrupted, lost, delayed, incomplete or amended. First City Monument Bank Plc and its subsidiaries do not accept liability for damage caused by this email or any attachments and may monitor email traffic.
Ang: Re: Ang: tdp for domino LAN free backup poor performance
Hi Sandeep If your hardware is working correctly, and tape operations from the TSM server shows good performance, I can only imagine two possible reasons for the low throughput: a) The disks connected to your Domino server isnt able to push the necessary MB/s to the tape drives thus creating start/write/stop/rewind/write/stop/rewind (and so on) sequences on your tape drives, a.k.a shoeshine effect. b) Your Domino server contains alot of small files. LAN-free to tape drives is only a benefit when transfering large chunks of data at a time, since all the meta data goes over the LAN anyway. So having a large amount of small files is certainly gonna give you shoeshine on your tape drives. This only goes for LAN-free to tape drives. For a file device class, you wont suffer throughput loss, but the metadata will still be sent over the LAN. Best Regards Daniel Daniel Sparrman Exist i Stockholm AB Växel: 08-754 98 00 Fax: 08-754 97 30 daniel.sparr...@exist.se http://www.existgruppen.se Posthusgatan 1 761 30 NORRTÄLJE -ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU skrev: - Till: ADSM-L@VM.MARIST.EDU Från: Sandeep Jain sandeep.j...@dcmds.com Sänt av: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Datum: 05/18/2011 09:01 Ärende: Re: Ang: tdp for domino LAN free backup poor performance Hi Daniel TDP through LAN takes 38 hours and LANfree takes 30 hours. I am also working on the OS/HARdware performance factor, I am too having doubt that the read I/O is slow... We are having HP server ProLiant DL180 G6 , windows 2003 64Bit , OS WIN2k3 64_bit Ent Ed. Lotus. 8.5.2 TDP for mail 5.5.3 Storage agent 5.5 Version of ibmtape device driver on the Domino windows host that controls tape drives---6.2.1.5 Regards Sandeep - Original Message - From: Daniel Sparrman daniel.sparr...@exist.se To: ADSM-L@vm.marist.edu Sent: Wednesday, May 18, 2011 10:20 AM Subject: [ADSM-L] Ang: tdp for domino LAN free backup poor performance Hi First off, there are several things that affect the performance except for just the optfile, software versions and your operating system: * What speed are you having making the backup over the LAN? * How fast are the disks on your Domino server, are they able to transfer data at the speeds your tape drives are writing? * How large are the files on your Domino server (average) ? * What's the version of the IBMtape driver on your Domino host? The version on your TSM server (which controls the library) really doesnt affect read/write performance since it only controls the robotics. Have you verified that the backup is actually being done across the SAN and not the LAN? 700GB in 30 hours is 23MB/s, which more looks like a slower than average LAN backup over gigabit ethernet. If your Domino server cant deliver data to the tapes drives with enough speed, you'll end up with a shoeshine effect, which will seriously reduce performance. Since you're using IBMtape, I'm assuming you're using some sort of LTO drives. If you for example have a LTO3 drive, it will write data @ 80MB/s natively. If your host only delivers data at 40MB/s, you will have a drive that is spending more time rewinding than actually writing the data. Some more information about your environment (hardware on both client server incl tape technology, your TDP configuration file) would be helpful in determining the error. Best Regards Daniel Sparrman Exist i Stockholm AB Växel: 08-754 98 00 Fax: 08-754 97 30 daniel.sparr...@exist.se http://www.existgruppen.se Posthusgatan 1 761 30 NORRTÄLJE -ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU skrev: - Till: ADSM-L@VM.MARIST.EDU Från: Sandeep Jain sandeep.j...@dcmds.com Sänt av: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Datum: 05/18/2011 06:54 Ärende: tdp for domino LAN free backup poor performance HI friends i am experiencing very very poor backup performance while taking backup of domino server. It is having around 700GB of data and LAN FREE backup on 2 tapes completing in 30 hours. OS WIN2k3 64_bit Ent Ed. Lotus. 8.5.2 TDP for mail 5.5.3 Storage agent 5.5 Version of ibmtape device driver on the Domino windows host that controls tape drives---6.2.1.5 i have also tried performance tunning parameters but no luck. DOMTXNGROUPMAX= 64 DOMTXNBYTELIMIT =2097152 dsm.opt *==* * * * IBM Tivoli Storage Manager for Mail * * Data Protection for Lotus Domino * * * * Sample Options File * * * *==* COMMMethod TCPip TCPPort 1500 TCPServeraddress 10.3.3.34 TCPWindowsize 63 TCPBuffSize 32 TXNBYTELIMIT 2097152 #12288; NODename domino_PDCHM_tdp PASSWORDAccess Generate #12288; SCHEDMODE Polling *SCHEDLOGRetention 14 *SCHEDMODE Prompted *TCPCLIENTADDRESS yy.yy.yy.yy *TCPCLIENTPORT 1502 enablelanfree yes
tdp for domino LAN free backup poor performance
HI friends i am experiencing very very poor backup performance while taking backup of domino server. It is having around 700GB of data and LAN FREE backup on 2 tapes completing in 30 hours. OS WIN2k3 64_bit Ent Ed. Lotus. 8.5.2 TDP for mail 5.5.3 Storage agent 5.5 Version of ibmtape device driver on the Domino windows host that controls tape drives---6.2.1.5 i have also tried performance tunning parameters but no luck. DOMTXNGROUPMAX= 64 DOMTXNBYTELIMIT =2097152 dsm.opt *==* * * * IBM Tivoli Storage Manager for Mail * * Data Protection for Lotus Domino * * * * Sample Options File * * * *==* COMMMethod TCPip TCPPort 1500 TCPServeraddress 10.3.3.34 TCPWindowsize 63 TCPBuffSize 32 TXNBYTELIMIT 2097152 NODename domino_PDCHM_tdp PASSWORDAccess Generate SCHEDMODE Polling *SCHEDLOGRetention 14 *SCHEDMODE Prompted *TCPCLIENTADDRESS yy.yy.yy.yy *TCPCLIENTPORT 1502 enablelanfree yes *lanfreecommmethod tcpip *lanfreetcpport 1500 COMPRESSIon NO COMPRESSAlways NO * Exclude all databases named db1.nsf regardless of where they appear *EXCLUDE db1.nsf * Exclude all databases that match help5_* in the help subdirectory *EXCLUDE help\help5_* * Include all databases in the mail6 directory *INCLUDE mail6\...\* * Assign all databases that match *.nsf in the mail subdirectory * to the MAILDB management class *INCLUDE mail\*.nsf* MAILDB * Exclude all databases in the mail6 subdirectory from compression *EXCLUDE.COMPRESSION mail6\...\* * Encrypt all databases in the mail5 directory *INCLUDE.ENCRYPT mail5\...\* * The Default include/exclude list follows: * * Note: You can back up the log.nsf database but you can only restore * it to an alternate name. * EXCLUDE log.nsf EXCLUDE mail.box * Include all transaction logs INCLUDE S*.TXN TCPNODELAY YES Regards Sandeep jain -- I am using the free version of SPAMfighter. We are a community of 7 million users fighting spam. SPAMfighter has removed 18254 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len The Professional version does not have this message Disclaimer: This e-mail is intended for the sole use of the recipient(s) and may contain confidential or privileged information. If you are not the intended recipient and receive this message in error, any dissemination, use, review, distribution, printing or copying of this message is strictly prohibited, and you are requested to notify the sender and destroy all copies of the original message. Thank you
Ang: tdp for domino LAN free backup poor performance
Hi First off, there are several things that affect the performance except for just the optfile, software versions and your operating system: * What speed are you having making the backup over the LAN? * How fast are the disks on your Domino server, are they able to transfer data at the speeds your tape drives are writing? * How large are the files on your Domino server (average) ? * What's the version of the IBMtape driver on your Domino host? The version on your TSM server (which controls the library) really doesnt affect read/write performance since it only controls the robotics. Have you verified that the backup is actually being done across the SAN and not the LAN? 700GB in 30 hours is 23MB/s, which more looks like a slower than average LAN backup over gigabit ethernet. If your Domino server cant deliver data to the tapes drives with enough speed, you'll end up with a shoeshine effect, which will seriously reduce performance. Since you're using IBMtape, I'm assuming you're using some sort of LTO drives. If you for example have a LTO3 drive, it will write data @ 80MB/s natively. If your host only delivers data at 40MB/s, you will have a drive that is spending more time rewinding than actually writing the data. Some more information about your environment (hardware on both client server incl tape technology, your TDP configuration file) would be helpful in determining the error. Best Regards Daniel Sparrman Exist i Stockholm AB Växel: 08-754 98 00 Fax: 08-754 97 30 daniel.sparr...@exist.se http://www.existgruppen.se Posthusgatan 1 761 30 NORRTÄLJE -ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU skrev: - Till: ADSM-L@VM.MARIST.EDU Från: Sandeep Jain sandeep.j...@dcmds.com Sänt av: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Datum: 05/18/2011 06:54 Ärende: tdp for domino LAN free backup poor performance HI friends i am experiencing very very poor backup performance while taking backup of domino server. It is having around 700GB of data and LAN FREE backup on 2 tapes completing in 30 hours. OS WIN2k3 64_bit Ent Ed. Lotus. 8.5.2 TDP for mail 5.5.3 Storage agent 5.5 Version of ibmtape device driver on the Domino windows host that controls tape drives---6.2.1.5 i have also tried performance tunning parameters but no luck. DOMTXNGROUPMAX= 64 DOMTXNBYTELIMIT =2097152 dsm.opt *==* * * * IBM Tivoli Storage Manager for Mail * * Data Protection for Lotus Domino * * * * Sample Options File * * * *==* COMMMethod TCPip TCPPort 1500 TCPServeraddress 10.3.3.34 TCPWindowsize 63 TCPBuffSize 32 TXNBYTELIMIT 2097152 #12288; NODename domino_PDCHM_tdp PASSWORDAccess Generate #12288; SCHEDMODE Polling *SCHEDLOGRetention 14 *SCHEDMODE Prompted *TCPCLIENTADDRESS yy.yy.yy.yy *TCPCLIENTPORT 1502 enablelanfree yes *lanfreecommmethod tcpip *lanfreetcpport 1500 #12288; COMPRESSIon NO COMPRESSAlways NO #12288; #12288; * Exclude all databases named db1.nsf regardless of where they appear *EXCLUDE db1.nsf * Exclude all databases that match help5_* in the help subdirectory *EXCLUDE help\help5_* * Include all databases in the mail6 directory *INCLUDE mail6\...\* * Assign all databases that match *.nsf in the mail subdirectory * to the MAILDB management class *INCLUDE mail\*.nsf* MAILDB * Exclude all databases in the mail6 subdirectory from compression *EXCLUDE.COMPRESSION mail6\...\* * Encrypt all databases in the mail5 directory *INCLUDE.ENCRYPT mail5\...\* * The Default include/exclude list follows: * * Note: You can back up the log.nsf database but you can only restore * it to an alternate name. * EXCLUDE log.nsf EXCLUDE mail.box * Include all transaction logs INCLUDE S*.TXN TCPNODELAY YES Regards Sandeep jain -- I am using the free version of SPAMfighter. We are a community of 7 million users fighting spam. SPAMfighter has removed 18254 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len The Professional version does not have this message Disclaimer: This e-mail is intended for the sole use of the recipient(s) and may contain confidential or privileged information. If you are not the intended recipient and receive this message in error, any dissemination, use, review, distribution, printing or copying of this message is strictly prohibited, and you are requested to notify the sender and destroy all copies of the original message. Thank you
TDP for Exchange - poor performance during online backup
I'm running Exchange Version 6.5.7638.1 under W2k3 Sever with TDP for Exchange 5.3.3. Running an online backup it starts with a data rate of aprx. 10 MB/sec. After some minutes this rate slows down to aprx. 1 MB/sec. The effect of this is, that a backup of aprx. 90 GB of data will last aprx. 30 hours. Does any body have an idea what's the reason for that strange behavior. Thanks Ron
Re: Windows 2000 and 2003 servers backups very poor performance
Thanks Justin and Miguel Miguel for the client we are using those recommended settings, they have been in place since we started backung up the clients. As for the TSM server settings I don't believe they need to be adjusted as we have many other clients that are running fine. Thanks Miguel Saez wrote: Review the following tunning: Client TSM: - Set Ethernet speed and duplex settings (Don't rely on Auto Detect) - Specifies: tcpwindowssize 63(recommended) 2048 (max) in KB tcpbufsize 32(recommended) 2048 (max) in KB tcpnodelay yes diskbuffsize 32 (recommended) 1023 (max) in KB compression yes Server TSM - Set Ethernet speed and duplex settings (Don't rely on Auto Detect) - Specifies BufPoolSize 131072 (for server with 1 GB RAM) UseLargeBuffers yes tcpwindowsize 63 (recommended)2048 (max) in KB tcpbuffsize 32 (recommended)2048 (max) in KB -- Use up to 3/4 of real memory for a dedicated TSM server (no other applications). tcpnodelayyes And Use dedicated networks for backup (LAN or SAN). Regards Miguel Sáez Sáez IBM Certified Deployment Professional Tivoli Configuration Manager IT Specialist IBM de Chile S.A.C. mail: [EMAIL PROTECTED] Phone: 562-2006638
Re: Windows 2000 and 2003 servers backups very poor performance
Thanksto all who responded I appreciate it. I will have a co-worker check the Nics and Switch first since that seems to be the place to start. Richard, I did take a look at the backup performance section and as I suspected several factors can affect a backup's performance. I was just curious as to if there was a setting in the clients the dsm.opt file that I could change that might make difference. Thanks again! Jeremy Curtis wrote: I agree on the speed/duplex. I have personally seen speed/duplex mismatch cause this. I don't personally have issues with Auto, just make sure both sides(server and switch) match. Jeremy Curtis Backup Administrator / Network Technician Vail Resorts, Inc. (970) 845-1921 -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Lipp Sent: Thursday, March 22, 2007 3:56 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance I will amplify Curtis' call on this: check the NICs. Especially if you are on 100MB Ethernet. For GigE, you generally can't choose, but make it all the same in the path between the server and TSM. As for testing: try an ftp of a large file (a gig or so so it stays on the wire for a minute or so). If this is faster than you are getting from TSM, you have a TSM problem. If it is the same speed, you have a network problem. Kelly J. Lipp VP Manufacturing CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Carpenter, Curtis Sent: Thursday, March 22, 2007 3:52 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance I would make sure whatever speed and duplex setting you have the nic set to, you should set the switch port to match. I would try to avoid setting both to autonegotiate, as I have personally seen horrible performance with that setting. Also, run diags on network interfaces to rule out any hardware problems. Are u using a seperate nic for your tivoli backups or are u using just one nic for all network communication on these servers? --Original Message-- From: Timothy Hughes To: ADSM-L ReplyTo: ADSM-L Sent: Mar 22, 2007 3:33 PM Subject: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance Hello, We have about 5 or 6 Windows Servers whose backups performance is very very poor these backups start a midnight and run throughout the whole day and sometimes run for a couple days I have been reading different options including the DISKBuffsize option, I know poor networking performance can be caused by a number of factors and not sure which parameter to look at first. Here is an example of one of the clients dsm.opt file, They all basically look the same and the parameters matches TSM windows clients recommendations. Lang Ameng Domain ALL-LOCAL TCPSERVERADDRESS .xxx.x.xx.xx Passwordaccess generate TCPCLIENTADDRESS xx.xx.xxx.xx NODENAME SUBDIR YES REPLACE PROMPT TCPB 32 TCPW 63 SCHEDMODE PROMPTED TXNBYTELIMIT 25600 ERRORLOGNAME SCHEDLOGNAME ERRORLOGRETENTION 14 SCHEDLOGRETENTION 7 TCPNODELAY YES RESOURCEUTILIZATION 3 LARGECOMMBUFFERS YES CHANGINGRETRIES 2 COMPRESSION BACKUPREG YES MANAGEDSERVICES WEBCLIENT SCHEDULE Windows 2000 and 2003 servers TSM server 5.3.4 TSM client 5.3.4
Re: Windows 2000 and 2003 servers backups very poor performance
We are using GigE and Curtis we are using a separate nic for tivoli backups. Thanks Tim Carpenter, Curtis wrote: I would make sure whatever speed and duplex setting you have the nic set to, you should set the switch port to match. I would try to avoid setting both to autonegotiate, as I have personally seen horrible performance with that setting. Also, run diags on network interfaces to rule out any hardware problems. Are u using a seperate nic for your tivoli backups or are u using just one nic for all network communication on these servers? --Original Message-- From: Timothy Hughes To: ADSM-L ReplyTo: ADSM-L Sent: Mar 22, 2007 3:33 PM Subject: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance Hello, We have about 5 or 6 Windows Servers whose backups performance is very very poor these backups start a midnight and run throughout the whole day and sometimes run for a couple days I have been reading different options including the DISKBuffsize option, I know poor networking performance can be caused by a number of factors and not sure which parameter to look at first. Here is an example of one of the clients dsm.opt file, They all basically look the same and the parameters matches TSM windows clients recommendations. Lang Ameng Domain ALL-LOCAL TCPSERVERADDRESS .xxx.x.xx.xx Passwordaccess generate TCPCLIENTADDRESS xx.xx.xxx.xx NODENAME SUBDIR YES REPLACE PROMPT TCPB 32 TCPW 63 SCHEDMODE PROMPTED TXNBYTELIMIT 25600 ERRORLOGNAME SCHEDLOGNAME ERRORLOGRETENTION 14 SCHEDLOGRETENTION 7 TCPNODELAY YES RESOURCEUTILIZATION 3 LARGECOMMBUFFERS YES CHANGINGRETRIES 2 COMPRESSION BACKUPREG YES MANAGEDSERVICES WEBCLIENT SCHEDULE Windows 2000 and 2003 servers TSM server 5.3.4 TSM client 5.3.4
Re: Windows 2000 and 2003 servers backups very poor performance
Doesn't matter the speed of your card if there is a mismatch on the nic and port. [EMAIL PROTECTED] 03/23/07 1:33 PM We are using GigE and Curtis we are using a separate nic for tivoli backups. Thanks Tim Carpenter, Curtis wrote: I would make sure whatever speed and duplex setting you have the nic set to, you should set the switch port to match. I would try to avoid setting both to autonegotiate, as I have personally seen horrible performance with that setting. Also, run diags on network interfaces to rule out any hardware problems. Are u using a seperate nic for your tivoli backups or are u using just one nic for all network communication on these servers? --Original Message-- From: Timothy Hughes To: ADSM-L ReplyTo: ADSM-L Sent: Mar 22, 2007 3:33 PM Subject: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance Hello, We have about 5 or 6 Windows Servers whose backups performance is very very poor these backups start a midnight and run throughout the whole day and sometimes run for a couple days I have been reading different options including the DISKBuffsize option, I know poor networking performance can be caused by a number of factors and not sure which parameter to look at first. Here is an example of one of the clients dsm.opt file, They all basically look the same and the parameters matches TSM windows clients recommendations. Lang Ameng Domain ALL-LOCAL TCPSERVERADDRESS .xxx.x.xx.xx Passwordaccess generate TCPCLIENTADDRESS xx.xx.xxx.xx NODENAME SUBDIR YES REPLACE PROMPT TCPB 32 TCPW 63 SCHEDMODE PROMPTED TXNBYTELIMIT 25600 ERRORLOGNAME SCHEDLOGNAME ERRORLOGRETENTION 14 SCHEDLOGRETENTION 7 TCPNODELAY YES RESOURCEUTILIZATION 3 LARGECOMMBUFFERS YES CHANGINGRETRIES 2 COMPRESSION BACKUPREG YES MANAGEDSERVICES WEBCLIENT SCHEDULE Windows 2000 and 2003 servers TSM server 5.3.4 TSM client 5.3.4 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain information that is confidential, privileged, and/or otherwise exempt from disclosure under applicable law. If this electronic message is from an attorney or someone in the Legal Department, it may also contain confidential attorney-client communications which may be privileged and protected from disclosure. If you are not the intended recipient, be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Please notify the New York State Thruway Authority immediately by either responding to this e-mail or calling (518) 436-2700, and destroy all copies of this message and any attachments.
Re: Windows 2000 and 2003 servers backups very poor performance
Hi Lawrence, I was informed there is no mismatch, and since that is the case I was curious since we are using GigE as opposed to what we used to before (100mb ethernet full) and the dsm.opt files were based on those settings could we adjust those parameters and is there any documentation or guides that says use different parameters for GigE. Thanks Tim Lawrence Clark wrote: Doesn't matter the speed of your card if there is a mismatch on the nic and port. [EMAIL PROTECTED] 03/23/07 1:33 PM We are using GigE and Curtis we are using a separate nic for tivoli backups. Thanks Tim Carpenter, Curtis wrote: I would make sure whatever speed and duplex setting you have the nic set to, you should set the switch port to match. I would try to avoid setting both to autonegotiate, as I have personally seen horrible performance with that setting. Also, run diags on network interfaces to rule out any hardware problems. Are u using a seperate nic for your tivoli backups or are u using just one nic for all network communication on these servers? --Original Message-- From: Timothy Hughes To: ADSM-L ReplyTo: ADSM-L Sent: Mar 22, 2007 3:33 PM Subject: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance Hello, We have about 5 or 6 Windows Servers whose backups performance is very very poor these backups start a midnight and run throughout the whole day and sometimes run for a couple days I have been reading different options including the DISKBuffsize option, I know poor networking performance can be caused by a number of factors and not sure which parameter to look at first. Here is an example of one of the clients dsm.opt file, They all basically look the same and the parameters matches TSM windows clients recommendations. Lang Ameng Domain ALL-LOCAL TCPSERVERADDRESS .xxx.x.xx.xx Passwordaccess generate TCPCLIENTADDRESS xx.xx.xxx.xx NODENAME SUBDIR YES REPLACE PROMPT TCPB 32 TCPW 63 SCHEDMODE PROMPTED TXNBYTELIMIT 25600 ERRORLOGNAME SCHEDLOGNAME ERRORLOGRETENTION 14 SCHEDLOGRETENTION 7 TCPNODELAY YES RESOURCEUTILIZATION 3 LARGECOMMBUFFERS YES CHANGINGRETRIES 2 COMPRESSION BACKUPREG YES MANAGEDSERVICES WEBCLIENT SCHEDULE Windows 2000 and 2003 servers TSM server 5.3.4 TSM client 5.3.4 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain information that is confidential, privileged, and/or otherwise exempt from disclosure under applicable law. If this electronic message is from an attorney or someone in the Legal Department, it may also contain confidential attorney-client communications which may be privileged and protected from disclosure. If you are not the intended recipient, be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Please notify the New York State Thruway Authority immediately by either responding to this e-mail or calling (518) 436-2700, and destroy all copies of this message and any attachments.
Re: Windows 2000 and 2003 servers backups very poor performance
Are you certain this is a network problem? I know we had similar problems with some Windows servers here and it turns out that TSM was spending hours and hours just scanning the files on the box because there were literally millions of them. We turned on the TSM journaling service and that dramtically cut down the overall backup time. Justin Timothy Hughes [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 03/23/2007 01:50 PM Please respond to ADSM: Dist Stor Manager To: ADSM-L@VM.MARIST.EDU cc: Subject:Re: [ADSM-L] Windows 2000 and 2003 servers backups very poor performance Hi Lawrence, I was informed there is no mismatch, and since that is the case I was curious since we are using GigE as opposed to what we used to before (100mb ethernet full) and the dsm.opt files were based on those settings could we adjust those parameters and is there any documentation or guides that says use different parameters for GigE. Thanks Tim Lawrence Clark wrote: Doesn't matter the speed of your card if there is a mismatch on the nic and port. [EMAIL PROTECTED] 03/23/07 1:33 PM We are using GigE and Curtis we are using a separate nic for tivoli backups. Thanks Tim Carpenter, Curtis wrote: I would make sure whatever speed and duplex setting you have the nic set to, you should set the switch port to match. I would try to avoid setting both to autonegotiate, as I have personally seen horrible performance with that setting. Also, run diags on network interfaces to rule out any hardware problems. Are u using a seperate nic for your tivoli backups or are u using just one nic for all network communication on these servers? --Original Message-- From: Timothy Hughes To: ADSM-L ReplyTo: ADSM-L Sent: Mar 22, 2007 3:33 PM Subject: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance Hello, We have about 5 or 6 Windows Servers whose backups performance is very very poor these backups start a midnight and run throughout the whole day and sometimes run for a couple days I have been reading different options including the DISKBuffsize option, I know poor networking performance can be caused by a number of factors and not sure which parameter to look at first. Here is an example of one of the clients dsm.opt file, They all basically look the same and the parameters matches TSM windows clients recommendations. Lang Ameng Domain ALL-LOCAL TCPSERVERADDRESS .xxx.x.xx.xx Passwordaccess generate TCPCLIENTADDRESS xx.xx.xxx.xx NODENAME SUBDIR YES REPLACE PROMPT TCPB 32 TCPW 63 SCHEDMODE PROMPTED TXNBYTELIMIT 25600 ERRORLOGNAME SCHEDLOGNAME ERRORLOGRETENTION 14 SCHEDLOGRETENTION 7 TCPNODELAY YES RESOURCEUTILIZATION 3 LARGECOMMBUFFERS YES CHANGINGRETRIES 2 COMPRESSION BACKUPREG YES MANAGEDSERVICES WEBCLIENT SCHEDULE Windows 2000 and 2003 servers TSM server 5.3.4 TSM client 5.3.4 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain information that is confidential, privileged, and/or otherwise exempt from disclosure under applicable law. If this electronic message is from an attorney or someone in the Legal Department, it may also contain confidential attorney-client communications which may be privileged and protected from disclosure. If you are not the intended recipient, be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Please notify the New York State Thruway Authority immediately by either responding to this e-mail or calling (518) 436-2700, and destroy all copies of this message and any attachments.
Re: Windows 2000 and 2003 servers backups very poor performance
Review the following tunning: Client TSM: - Set Ethernet speed and duplex settings (Don't rely on Auto Detect) - Specifies: tcpwindowssize 63(recommended) 2048 (max) in KB tcpbufsize 32(recommended) 2048 (max) in KB tcpnodelay yes diskbuffsize 32 (recommended) 1023 (max) in KB compression yes Server TSM - Set Ethernet speed and duplex settings (Don't rely on Auto Detect) - Specifies BufPoolSize 131072 (for server with 1 GB RAM) UseLargeBuffers yes tcpwindowsize 63 (recommended)2048 (max) in KB tcpbuffsize 32 (recommended)2048 (max) in KB -- Use up to 3/4 of real memory for a dedicated TSM server (no other applications). tcpnodelayyes And Use dedicated networks for backup (LAN or SAN). Regards Miguel Sáez Sáez IBM Certified Deployment Professional Tivoli Configuration Manager IT Specialist IBM de Chile S.A.C. mail: [EMAIL PROTECTED] Phone: 562-2006638
Wiindows 2000 and 2003 servers backups very poor performance
Hello, We have about 5 or 6 Windows Servers whose backups performance is very very poor these backups start a midnight and run throughout the whole day and sometimes run for a couple days I have been reading different options including the DISKBuffsize option, I know poor networking performance can be caused by a number of factors and not sure which parameter to look at first. Here is an example of one of the clients dsm.opt file, They all basically look the same and the parameters matches TSM windows clients recommendations. Lang Ameng Domain ALL-LOCAL TCPSERVERADDRESS .xxx.x.xx.xx Passwordaccess generate TCPCLIENTADDRESS xx.xx.xxx.xx NODENAME SUBDIR YES REPLACE PROMPT TCPB 32 TCPW 63 SCHEDMODE PROMPTED TXNBYTELIMIT 25600 ERRORLOGNAME SCHEDLOGNAME ERRORLOGRETENTION 14 SCHEDLOGRETENTION 7 TCPNODELAY YES RESOURCEUTILIZATION 3 LARGECOMMBUFFERS YES CHANGINGRETRIES 2 COMPRESSION BACKUPREG YES MANAGEDSERVICES WEBCLIENT SCHEDULE Windows 2000 and 2003 servers TSM server 5.3.4 TSM client 5.3.4
Re: Wiindows 2000 and 2003 servers backups very poor performance
Try setting the NIC cards to 100 mb Full duplex. Also the switch port (if they're connected to switches) to match. Lamarr Kelley Network Specialist II Information Technology Huntsville Hospital (c) 256-990-5003 (o) 256-265-9112 Confidentiality Note: http://www.huntsvillehospital.org/footer/disclaimer/ -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Hughes Sent: Thursday, March 22, 2007 2:33 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance Hello, We have about 5 or 6 Windows Servers whose backups performance is very very poor these backups start a midnight and run throughout the whole day and sometimes run for a couple days I have been reading different options including the DISKBuffsize option, I know poor networking performance can be caused by a number of factors and not sure which parameter to look at first. Here is an example of one of the clients dsm.opt file, They all basically look the same and the parameters matches TSM windows clients recommendations. Lang Ameng Domain ALL-LOCAL TCPSERVERADDRESS .xxx.x.xx.xx Passwordaccess generate TCPCLIENTADDRESS xx.xx.xxx.xx NODENAME SUBDIR YES REPLACE PROMPT TCPB 32 TCPW 63 SCHEDMODE PROMPTED TXNBYTELIMIT 25600 ERRORLOGNAME SCHEDLOGNAME ERRORLOGRETENTION 14 SCHEDLOGRETENTION 7 TCPNODELAY YES RESOURCEUTILIZATION 3 LARGECOMMBUFFERS YES CHANGINGRETRIES 2 COMPRESSION BACKUPREG YES MANAGEDSERVICES WEBCLIENT SCHEDULE Windows 2000 and 2003 servers TSM server 5.3.4 TSM client 5.3.4 Confidentiality Note: http://www.huntsvillehospital.org/footer/disclaimer/ Confidentiality Note: http://www.huntsvillehospital.org/footer/disclaimer/
Re: Wiindows 2000 and 2003 servers backups very poor performance
Not alwaysbut on a number of occassions I seen long running backups on Windows servers because they have the nic card set at an explicit setting, and the network has auto-negotiate on the ports, or some such mismatch between the client NIC and the port config. [EMAIL PROTECTED] 03/22/07 2:33 PM Hello, We have about 5 or 6 Windows Servers whose backups performance is very very poor these backups start a midnight and run throughout the whole day and sometimes run for a couple days I have been reading different options including the DISKBuffsize option, I know poor networking performance can be caused by a number of factors and not sure which parameter to look at first. Here is an example of one of the clients dsm.opt file, They all basically look the same and the parameters matches TSM windows clients recommendations. Lang Ameng Domain ALL-LOCAL TCPSERVERADDRESS .xxx.x.xx.xx Passwordaccess generate TCPCLIENTADDRESS xx.xx.xxx.xx NODENAME SUBDIR YES REPLACE PROMPT TCPB 32 TCPW 63 SCHEDMODE PROMPTED TXNBYTELIMIT 25600 ERRORLOGNAME SCHEDLOGNAME ERRORLOGRETENTION 14 SCHEDLOGRETENTION 7 TCPNODELAY YES RESOURCEUTILIZATION 3 LARGECOMMBUFFERS YES CHANGINGRETRIES 2 COMPRESSION BACKUPREG YES MANAGEDSERVICES WEBCLIENT SCHEDULE Windows 2000 and 2003 servers TSM server 5.3.4 TSM client 5.3.4 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain information that is confidential, privileged, and/or otherwise exempt from disclosure under applicable law. If this electronic message is from an attorney or someone in the Legal Department, it may also contain confidential attorney-client communications which may be privileged and protected from disclosure. If you are not the intended recipient, be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Please notify the New York State Thruway Authority immediately by either responding to this e-mail or calling (518) 436-2700, and destroy all copies of this message and any attachments.
Re: Wiindows 2000 and 2003 servers backups very poor performance
I would make sure whatever speed and duplex setting you have the nic set to, you should set the switch port to match. I would try to avoid setting both to autonegotiate, as I have personally seen horrible performance with that setting. Also, run diags on network interfaces to rule out any hardware problems. Are u using a seperate nic for your tivoli backups or are u using just one nic for all network communication on these servers? --Original Message-- From: Timothy Hughes To: ADSM-L ReplyTo: ADSM-L Sent: Mar 22, 2007 3:33 PM Subject: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance Hello, We have about 5 or 6 Windows Servers whose backups performance is very very poor these backups start a midnight and run throughout the whole day and sometimes run for a couple days I have been reading different options including the DISKBuffsize option, I know poor networking performance can be caused by a number of factors and not sure which parameter to look at first. Here is an example of one of the clients dsm.opt file, They all basically look the same and the parameters matches TSM windows clients recommendations. Lang Ameng Domain ALL-LOCAL TCPSERVERADDRESS .xxx.x.xx.xx Passwordaccess generate TCPCLIENTADDRESS xx.xx.xxx.xx NODENAME SUBDIR YES REPLACE PROMPT TCPB 32 TCPW 63 SCHEDMODE PROMPTED TXNBYTELIMIT 25600 ERRORLOGNAME SCHEDLOGNAME ERRORLOGRETENTION 14 SCHEDLOGRETENTION 7 TCPNODELAY YES RESOURCEUTILIZATION 3 LARGECOMMBUFFERS YES CHANGINGRETRIES 2 COMPRESSION BACKUPREG YES MANAGEDSERVICES WEBCLIENT SCHEDULE Windows 2000 and 2003 servers TSM server 5.3.4 TSM client 5.3.4
Re: Wiindows 2000 and 2003 servers backups very poor performance
I will amplify Curtis' call on this: check the NICs. Especially if you are on 100MB Ethernet. For GigE, you generally can't choose, but make it all the same in the path between the server and TSM. As for testing: try an ftp of a large file (a gig or so so it stays on the wire for a minute or so). If this is faster than you are getting from TSM, you have a TSM problem. If it is the same speed, you have a network problem. Kelly J. Lipp VP Manufacturing CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Carpenter, Curtis Sent: Thursday, March 22, 2007 3:52 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance I would make sure whatever speed and duplex setting you have the nic set to, you should set the switch port to match. I would try to avoid setting both to autonegotiate, as I have personally seen horrible performance with that setting. Also, run diags on network interfaces to rule out any hardware problems. Are u using a seperate nic for your tivoli backups or are u using just one nic for all network communication on these servers? --Original Message-- From: Timothy Hughes To: ADSM-L ReplyTo: ADSM-L Sent: Mar 22, 2007 3:33 PM Subject: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance Hello, We have about 5 or 6 Windows Servers whose backups performance is very very poor these backups start a midnight and run throughout the whole day and sometimes run for a couple days I have been reading different options including the DISKBuffsize option, I know poor networking performance can be caused by a number of factors and not sure which parameter to look at first. Here is an example of one of the clients dsm.opt file, They all basically look the same and the parameters matches TSM windows clients recommendations. Lang Ameng Domain ALL-LOCAL TCPSERVERADDRESS .xxx.x.xx.xx Passwordaccess generate TCPCLIENTADDRESS xx.xx.xxx.xx NODENAME SUBDIR YES REPLACE PROMPT TCPB 32 TCPW 63 SCHEDMODE PROMPTED TXNBYTELIMIT 25600 ERRORLOGNAME SCHEDLOGNAME ERRORLOGRETENTION 14 SCHEDLOGRETENTION 7 TCPNODELAY YES RESOURCEUTILIZATION 3 LARGECOMMBUFFERS YES CHANGINGRETRIES 2 COMPRESSION BACKUPREG YES MANAGEDSERVICES WEBCLIENT SCHEDULE Windows 2000 and 2003 servers TSM server 5.3.4 TSM client 5.3.4
Re: Wiindows 2000 and 2003 servers backups very poor performance
I agree on the speed/duplex. I have personally seen speed/duplex mismatch cause this. I don't personally have issues with Auto, just make sure both sides(server and switch) match. Jeremy Curtis Backup Administrator / Network Technician Vail Resorts, Inc. (970) 845-1921 -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Lipp Sent: Thursday, March 22, 2007 3:56 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance I will amplify Curtis' call on this: check the NICs. Especially if you are on 100MB Ethernet. For GigE, you generally can't choose, but make it all the same in the path between the server and TSM. As for testing: try an ftp of a large file (a gig or so so it stays on the wire for a minute or so). If this is faster than you are getting from TSM, you have a TSM problem. If it is the same speed, you have a network problem. Kelly J. Lipp VP Manufacturing CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Carpenter, Curtis Sent: Thursday, March 22, 2007 3:52 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance I would make sure whatever speed and duplex setting you have the nic set to, you should set the switch port to match. I would try to avoid setting both to autonegotiate, as I have personally seen horrible performance with that setting. Also, run diags on network interfaces to rule out any hardware problems. Are u using a seperate nic for your tivoli backups or are u using just one nic for all network communication on these servers? --Original Message-- From: Timothy Hughes To: ADSM-L ReplyTo: ADSM-L Sent: Mar 22, 2007 3:33 PM Subject: [ADSM-L] Wiindows 2000 and 2003 servers backups very poor performance Hello, We have about 5 or 6 Windows Servers whose backups performance is very very poor these backups start a midnight and run throughout the whole day and sometimes run for a couple days I have been reading different options including the DISKBuffsize option, I know poor networking performance can be caused by a number of factors and not sure which parameter to look at first. Here is an example of one of the clients dsm.opt file, They all basically look the same and the parameters matches TSM windows clients recommendations. Lang Ameng Domain ALL-LOCAL TCPSERVERADDRESS .xxx.x.xx.xx Passwordaccess generate TCPCLIENTADDRESS xx.xx.xxx.xx NODENAME SUBDIR YES REPLACE PROMPT TCPB 32 TCPW 63 SCHEDMODE PROMPTED TXNBYTELIMIT 25600 ERRORLOGNAME SCHEDLOGNAME ERRORLOGRETENTION 14 SCHEDLOGRETENTION 7 TCPNODELAY YES RESOURCEUTILIZATION 3 LARGECOMMBUFFERS YES CHANGINGRETRIES 2 COMPRESSION BACKUPREG YES MANAGEDSERVICES WEBCLIENT SCHEDULE Windows 2000 and 2003 servers TSM server 5.3.4 TSM client 5.3.4
Re: poor performance
Hi, before seriously looking into your HW-configuration and disk layout you should rule out any paging space issues and lack of I/O-tuning. Check paging space activity with vmstat or nmon. Consistant activity to and from paging space during dbbackup/expiration indicates you have a memory/tuning problem and will drastically reduce performance. Are you using files or raw volumes for your db, log and diskpools? Using files increases the need for proper tuning. Your other server performed OK? You should check if the OS-tuning is the same on the new server. These are set in the file /etc/tunables/nextboot. Best of luck, Hans C. Riksheim -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Gill, Geoffrey L. Sent: Friday, August 18, 2006 5:45 AM To: ADSM-L@VM.MARIST.EDU Subject: poor performance Although I have an open issue with TSM and AIX support on poor performance I was wondering if anyone might want to chime in on this subject. This are taking way too long on a 4 processor system that took 1/3 the time on my 2 processor box. Db backups are 5+ hours on a 120gb db that is 35% used. Expiration is taking forever, backups are still running in the AM when I get in. Any thoughts from anyone? TSM 5.3.3.0 on AIX 5.3 Thanks, Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-G1b (858)826-4062 Email: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: poor performance
4 full D40s, JBOD, for the database? Ouchie. There's my leading candidate for performance problems. I suggest one VG with a bunch of non-raided disks in it, raw LVs one or two to a spindle, with mirrors on separate spindles, for DB and log. To be more clear. The 4 D40's are a mixture of database, logs and disk pools. One VG for database, one for mirrored database and one for data storage pools. Four full D40's just for a database would be quite unnecessary. No raid anywhere, all raw disk consisting of one LV per disk no matter if it is database, log or disk pool related. Mirrors are absolutely on separate spindles which are also on separate D40's. Thanks, Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-G1b (858)826-4062 Email: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: poor performance
How may disks are in the vg for the db? How many disk are in the vg for the mirror of the db? How big are the disk drives? I assume that when you watch topas you see very high wait-for-I/O percent and little actual cpu being used. Does a iostat show even activity on the disks for db and log? Gill, Geoffrey L. GEOFFREY.L.GILL@ To SAIC.COM ADSM-L@VM.MARIST.EDU Sent by: ADSM:cc Dist Stor Manager Subject [EMAIL PROTECTED] Re: poor performance .EDU 08/21/2006 11:43 AM Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] .EDU 4 full D40s, JBOD, for the database? Ouchie. There's my leading candidate for performance problems. I suggest one VG with a bunch of non-raided disks in it, raw LVs one or two to a spindle, with mirrors on separate spindles, for DB and log. To be more clear. The 4 D40's are a mixture of database, logs and disk pools. One VG for database, one for mirrored database and one for data storage pools. Four full D40's just for a database would be quite unnecessary. No raid anywhere, all raw disk consisting of one LV per disk no matter if it is database, log or disk pool related. Mirrors are absolutely on separate spindles which are also on separate D40's. Thanks, Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-G1b (858)826-4062 Email: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: poor performance
On Mon, 21 Aug 2006 08:43:26 -0700, Gill, Geoffrey L. [EMAIL PROTECTED] said: To be more clear. The 4 D40's are a mixture of database, logs and disk pools. One VG for database, one for mirrored database and one for data storage pools. Mkay; good. :) What size disks? were these the same disks as on your previous setup? When I moved from 9G to 18G spindles for databases, I found that having DB volumes fill the spindle blew my performance for ( I inferred ) contention reasons. You said 120GB; I'll presume that's available space. Even with 36G SSA, that's just 4 volumes, 4 threads with which DB work can be done. For comparison's sake, with 316GB of aggregate available databse space, I have 35 volumes defined, mostly on 18G spindles. Now, I'm in a very different environment, 11 servers on that piece of hardware. But even so, you get the sense. My largest single DB, ~70G, has 8 (mirrored) volumes. I think it possible that you will see performance improvement if you merely cut your DB volume size. Don't go nuts, there's certainly a performance trainwreck at the other side of the scale, too: dozens of DB vols per spindle is Right Out. But you might consider 2 or 3 if you're at 36G, maybe even more if you're at 72. Four full D40's just for a database would be quite unnecessary. Agreed, though I wasn't visualizing that; I was visualizing one JBOD RAID (raid-0?) with LVs carved out for whatever purposes. No raid anywhere, all raw disk consisting of one LV per disk no matter if it is database, log or disk pool related. Digression: strongly suggest RAID for the data pools. 5-disk RAIDs seem to be good performance for SSA, and then you have a hot spare 1/drawer. Pedantic comment: If you're doing LVM with unraided disks, I'm not sure JBOD applies. Isn't that a RAID term-of-art? Gratuitous label: things come in threes. - Allen S. Rout
Re: poor performance
What size disks? were these the same disks as on your previous setup? All disks are 36GB. Yes, these are the same size as the previous setup. Available space is 132GB assigned capacity is 120GB. The difference would be in the number of db volumes. The old system has 9, 3 on each 36GB disk the new just 4, one on each on the 4 disks. Sounds like I should work on splitting those volumes and put 3 on each disk since they are 36GB each. I guess I didn't expect, (IF this a huge source of my problems) that this would make that much difference. Thanks, Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-G1b (858)826-4062 Email: [EMAIL PROTECTED]
Re: poor performance
Geoff - Do a physical inspection of the D40s, in particular looking for blinking lights indicating incomplete SSA loops which degrade performance. Your AIX Error Log may also hold indications of problems. All the usual system tuning considerations need to be pursued. One of the first things I would look at is memory and paging space. If you are running a TSM client on that TSM server, use dsmcad rather than dsmc schedule, to avoid tying up vital memory in perpetuity. I would also conduct relative performance measurements, comparing I/O performance for a given write load to the external SSA vs. the same to internal disk. In not using RAID for your D40 disks, you're giving up a great opportunity for performance. I'm using RAID 1+0 on D40 SSA and am enjoying great performance. Make the most of the available technology. Richard Sims
Re: poor performance
Further investigation with support on this particular question and the number of db volumes per spindle, I received the following reply: We have no recommendation on that, because it can be so environment specific. The hardware is IBM so why not have a recommendation? I find it awful disappointing to know that after all these years IBM has absolutely no performance recommendations to give on their own product. With all the hardware they make and money to test on, at least the platforms they support, you'd think they'd have some recommendation or at least venture to speculate. After all, how many of these performance tickets do you think they've had since the inception of ADSM? Thanks, Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-G1b (858)826-4062 Email: [EMAIL PROTECTED] -Original Message- From: Gill, Geoffrey L. Sent: Monday, August 21, 2006 2:48 PM To: 'ADSM: Dist Stor Manager' Subject: RE: poor performance What size disks? were these the same disks as on your previous setup? All disks are 36GB. Yes, these are the same size as the previous setup. Available space is 132GB assigned capacity is 120GB. The difference would be in the number of db volumes. The old system has 9, 3 on each 36GB disk the new just 4, one on each on the 4 disks. Sounds like I should work on splitting those volumes and put 3 on each disk since they are 36GB each. I guess I didn't expect, (IF this a huge source of my problems) that this would make that much difference. Thanks, Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-G1b (858)826-4062 Email: [EMAIL PROTECTED]
Re: poor performance
On Fri, 18 Aug 2006 09:23:06 -0700, Gill, Geoffrey L. [EMAIL PROTECTED] said: This is a 6h1 with 4 processors and 4Gb memory. Disks are SSA, 2 controllers and 4 full D40's for TSM DB, Logs and disk pools. All disk JBOD. GIG nic that when at it's peak only 50% utilized. 4 full D40s, JBOD, for the database? Ouchie. There's my leading candidate for performance problems. I suggest one VG with a bunch of non-raided disks in it, raw LVs one or two to a spindle, with mirrors on separate spindles, for DB and log. - Allen S. Rout
Re: poor performance
What's the hardware, what's the underlying DB disk tech, how much memory, etc? What's your assessment of the database cache size? This is a 6h1 with 4 processors and 4Gb memory. Disks are SSA, 2 controllers and 4 full D40's for TSM DB, Logs and disk pools. All disk JBOD. GIG nic that when at it's peak only 50% utilized. Cache hit pct is consistently steady at over 99%. Database is 120GB at 33% utilized. Database backups are running at about 4.5 hours to complete. Bufpool size is 524288, which matches the older server and all other options are also identical to the older server. Backups themselves seem to have slowed as I've added more clients to backup. This morning there are still 24 servers running. While on the M80 I never saw this. The M80 is similar in configuration, but only 2 CPU's, which is why I pretty much mirrored it when building this one. The newer system however is pretty much a dog right now. Thanks, Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-G1b (858)826-4062 Email: [EMAIL PROTECTED] Thanks, Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-G1b (858)826-4062 Email: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: poor performance
Double check your SSA loops, adapter settings, and AIX IO tuning. This very much sounds like a disk IO problem. Orville L. Lantto Glasshouse Technologies, Inc. From: ADSM: Dist Stor Manager on behalf of Gill, Geoffrey L. Sent: Fri 8/18/2006 11:23 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] poor performance What's the hardware, what's the underlying DB disk tech, how much memory, etc? What's your assessment of the database cache size? This is a 6h1 with 4 processors and 4Gb memory. Disks are SSA, 2 controllers and 4 full D40's for TSM DB, Logs and disk pools. All disk JBOD. GIG nic that when at it's peak only 50% utilized. Cache hit pct is consistently steady at over 99%. Database is 120GB at 33% utilized. Database backups are running at about 4.5 hours to complete. Bufpool size is 524288, which matches the older server and all other options are also identical to the older server. Backups themselves seem to have slowed as I've added more clients to backup. This morning there are still 24 servers running. While on the M80 I never saw this. The M80 is similar in configuration, but only 2 CPU's, which is why I pretty much mirrored it when building this one. The newer system however is pretty much a dog right now. Thanks, Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-G1b (858)826-4062 Email: [EMAIL PROTECTED] Thanks, Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-G1b (858)826-4062 Email: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
poor performance
Although I have an open issue with TSM and AIX support on poor performance I was wondering if anyone might want to chime in on this subject. This are taking way too long on a 4 processor system that took 1/3 the time on my 2 processor box. Db backups are 5+ hours on a 120gb db that is 35% used. Expiration is taking forever, backups are still running in the AM when I get in. Any thoughts from anyone? TSM 5.3.3.0 on AIX 5.3 Thanks, Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-G1b (858)826-4062 Email: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Poor performance with TSM Storage Agent on Solaris
Hi Paul, I have just now performed a server trace on the storage agent, but I havent had the time to look at it yet. I am not completely sure which trace classes to enable but I will experiment a little. The disk is SAN-attached HDS lightning disks, so disk performance is not an issue, and it is the same disk where we see 60mb/s. Also, I get the same performance from each session regardless of how many sessions there are in parallel. 60mb/s is per session.. and that is what the 9840C drives should deliver (35mb/s native, 70mb compressed). We previously had 9840B drives which only delivered 20mb/s native, and thus didnt really see the problem. We have terabyte sized databases so we really need all the speed we can get. I am currently in the process of filling out a performance questionnaire to IBMs performance team regarding this issue. -David -- David Hendén Exist AB, Sweden +46 70 3992759 P Baines [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 2005-02-24 12:22 Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc Subject Re: Poor performance with TSM Storage Agent on Solaris Have you run a client performance trace? This may give you an idea about where the client is spending it's time. What type of disk is the data stored on that you want to back-up from/restore to? Are these the same type of disks where you see 60MB/sec? (How many parallel sessions do you run to get 60MB/sec?) I also have problems getting good backup rates on LAN-Free and my investigations are leading me to believe that the bottle-neck is the client disk. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of David Hendén Sent: Wednesday 23 February 2005 17:43 To: ADSM-L@VM.MARIST.EDU Subject: Poor performance with TSM Storage Agent on Solaris Dear all, We are experiencing performance problems with the TSM Storage Agent for Solaris. This is regardless of if we are doing restores or backups. The problem manifests itself mainly when restoring or backing data with DB2, but I get the same poor performance when sending gig sized files from the file system. Performance seems to be CPU bound, and each restore/backup session takes 100% of one CPU. So, on a 400mHz machine I can get around 10-15mb/s lanfree and on the faster machines with 1200mHz CPUs we're seeing speeds of around 20mb/s. When specifying parallelism in the DB2 databases to use multiple sessions we get 2 * 10-15mb/s and also 2 CPUs using 100%. Truss says that almost all of this CPU time is spent in userland. The native speed of the 9840C drives is 35mb/s and on AIX machines and Slowlaris machines with Oracle we see speeds of about 60mb/s per session over the SAN. At first I thought it could be the loopback interface but I didnt see any performance gain when switching to shared memory. I have also tried all the performance recommendations by IBM. I am going to trace the storage agent tomorrow to see if I can shed some light on what all the CPU time is spent on. On to my questions: Has anyone experienced the same extreme CPU load when using the storage agent on Solaris? Could it possibly be a patch related problem since the Solaris Oracle machines are more heavily patched than the DB2 ditos? The environment: Serverside: TSM server 5.2.3.2 on AIX 5.2. 16 StorageTek 9840C tape drives in powderhorn libraries using ACSLS. Everything is SAN connected with Cisco directors. Clientside: Solaris 5.8 64bit kernel. Gresham EDT 6.4.3.0 used to connect to the ACSLS. Storage Agent 5.2.3.5 on Solaris 5.8. TSM client 5.2.3.5. A range of different SUN hardware: different machines, different HBAs (both Sbus and PCI). -David -- David Hendén Exist AB, Sweden +46 70 3992759 Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither be binding nor construed as constituting a commitment by the ECB except where provided for in a written agreement. This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system.
Re: Poor performance with TSM Storage Agent on Solaris
Have you run a client performance trace? This may give you an idea about where the client is spending it's time. What type of disk is the data stored on that you want to back-up from/restore to? Are these the same type of disks where you see 60MB/sec? (How many parallel sessions do you run to get 60MB/sec?) I also have problems getting good backup rates on LAN-Free and my investigations are leading me to believe that the bottle-neck is the client disk. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of David Hendén Sent: Wednesday 23 February 2005 17:43 To: ADSM-L@VM.MARIST.EDU Subject: Poor performance with TSM Storage Agent on Solaris Dear all, We are experiencing performance problems with the TSM Storage Agent for Solaris. This is regardless of if we are doing restores or backups. The problem manifests itself mainly when restoring or backing data with DB2, but I get the same poor performance when sending gig sized files from the file system. Performance seems to be CPU bound, and each restore/backup session takes 100% of one CPU. So, on a 400mHz machine I can get around 10-15mb/s lanfree and on the faster machines with 1200mHz CPUs we're seeing speeds of around 20mb/s. When specifying parallelism in the DB2 databases to use multiple sessions we get 2 * 10-15mb/s and also 2 CPUs using 100%. Truss says that almost all of this CPU time is spent in userland. The native speed of the 9840C drives is 35mb/s and on AIX machines and Slowlaris machines with Oracle we see speeds of about 60mb/s per session over the SAN. At first I thought it could be the loopback interface but I didnt see any performance gain when switching to shared memory. I have also tried all the performance recommendations by IBM. I am going to trace the storage agent tomorrow to see if I can shed some light on what all the CPU time is spent on. On to my questions: Has anyone experienced the same extreme CPU load when using the storage agent on Solaris? Could it possibly be a patch related problem since the Solaris Oracle machines are more heavily patched than the DB2 ditos? The environment: Serverside: TSM server 5.2.3.2 on AIX 5.2. 16 StorageTek 9840C tape drives in powderhorn libraries using ACSLS. Everything is SAN connected with Cisco directors. Clientside: Solaris 5.8 64bit kernel. Gresham EDT 6.4.3.0 used to connect to the ACSLS. Storage Agent 5.2.3.5 on Solaris 5.8. TSM client 5.2.3.5. A range of different SUN hardware: different machines, different HBAs (both Sbus and PCI). -David -- David Hendén Exist AB, Sweden +46 70 3992759 Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither be binding nor construed as constituting a commitment by the ECB except where provided for in a written agreement. This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system.
Poor performance with TSM Storage Agent on Solaris
Dear all, We are experiencing performance problems with the TSM Storage Agent for Solaris. This is regardless of if we are doing restores or backups. The problem manifests itself mainly when restoring or backing data with DB2, but I get the same poor performance when sending gig sized files from the file system. Performance seems to be CPU bound, and each restore/backup session takes 100% of one CPU. So, on a 400mHz machine I can get around 10-15mb/s lanfree and on the faster machines with 1200mHz CPUs we're seeing speeds of around 20mb/s. When specifying parallelism in the DB2 databases to use multiple sessions we get 2 * 10-15mb/s and also 2 CPUs using 100%. Truss says that almost all of this CPU time is spent in userland. The native speed of the 9840C drives is 35mb/s and on AIX machines and Slowlaris machines with Oracle we see speeds of about 60mb/s per session over the SAN. At first I thought it could be the loopback interface but I didnt see any performance gain when switching to shared memory. I have also tried all the performance recommendations by IBM. I am going to trace the storage agent tomorrow to see if I can shed some light on what all the CPU time is spent on. On to my questions: Has anyone experienced the same extreme CPU load when using the storage agent on Solaris? Could it possibly be a patch related problem since the Solaris Oracle machines are more heavily patched than the DB2 ditos? The environment: Serverside: TSM server 5.2.3.2 on AIX 5.2. 16 StorageTek 9840C tape drives in powderhorn libraries using ACSLS. Everything is SAN connected with Cisco directors. Clientside: Solaris 5.8 64bit kernel. Gresham EDT 6.4.3.0 used to connect to the ACSLS. Storage Agent 5.2.3.5 on Solaris 5.8. TSM client 5.2.3.5. A range of different SUN hardware: different machines, different HBAs (both Sbus and PCI). -David -- David Hendén Exist AB, Sweden +46 70 3992759
Re: Poor Performance
my knowledge in Cisco devices also is very far from expert level I so consulted with a colleague. His answer was the same - there is no Cisco device to mess with your TCP stream. You can have a switch (at OSI layer 2) which deals with Ethernet frames, a router forwarding IP packets or L3 switch looking inside Ethernet frames and switching IP packets (at OSI layer 3), some application (HTTP) load-balancers acting as application proxies which multiplex requests to several hosts (at OSI layer 7). You do not have a TSM connection from port 1500 or to port 1500 on Cisco device. You can have a configuration: HostA -- (1 or more) Cisco -- HostB The traffic through these Cisco devices is either Ethernet frames or IP packets. Only HostA and HostB assemble IP packets into TCP stream and only their TCP-window sizes affect the connection. Cisco in the middle can drop frames, drop or fragment IP packets and thus reduce throughput but cannot interfere with TCP stream. Zlatko Krastev IT Consultant Salak Juraj [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 15.11.2002 13:38 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: Poor Performance Hello, up to my (non-expert) knowledge you can set tcp window size on various cisco devices. The default seems to be 4128, the command to change it is ip tcp window-size 0-65535 I never tried to change it ;) regards Juraj Salak Es gibt tatsächlich auf den Cisco Geräten einen Befehl der die Windowsize betrifft (ip tcp window-size 0-65535), standardmäßig steht dieser Wert auf 4128. Wenn ich das richtig interpretiere würde das bedeuten dass bis zu 4128 -Original Message- From: Zlatko Krastev [mailto:[EMAIL PROTECTED]] Sent: Friday, November 15, 2002 1:14 AM To: [EMAIL PROTECTED] Subject: Re: Poor Performance What kind of Cisco is this? I am unaware of any Cisco non-networking device (if we assume iSCSI as half-networking) and networking ones should not mess with your TCP (OSI level 4; they ought to deal with IP - OSI level 3). Even if it really does look inside TCP stream it should not limit you to only 16kB! They ought to support RFC1323 and TCP window larger than 64 kB. Zlatko Krastev IT Consultant Lawrie Scott [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 12.11.2002 10:53 Please respond to Lawrie Scott To: [EMAIL PROTECTED] cc: Subject:Re: Poor Performance Hi all Thanx for all the replies some of the tricks have helped a bit. However the TCPWindowsSize of 16 is set as CISCO has a limitation of TCPwindowsize of 16 and whenever we increase it to 63 the server then begins to timeout server requests and no backups happen. Lawrie Scott For: Persetel / Q Vector KZN Company Registration Number: 1993/003683/07 Tel: +27 (0) 31 5609222 Fax: +27 (0) 31 5609495 Cell: +27 (0) 835568488 E-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Re: Poor Performance
Hello, up to my (non-expert) knowledge you can set tcp window size on various cisco devices. The default seems to be 4128, the command to change it is ip tcp window-size 0-65535 I never tried to change it ;) regards Juraj Salak Es gibt tatsächlich auf den Cisco Geräten einen Befehl der die Windowsize betrifft (ip tcp window-size 0-65535), standardmäßig steht dieser Wert auf 4128. Wenn ich das richtig interpretiere würde das bedeuten dass bis zu 4128 -Original Message- From: Zlatko Krastev [mailto:acit;ATTGLOBAL.NET] Sent: Friday, November 15, 2002 1:14 AM To: [EMAIL PROTECTED] Subject: Re: Poor Performance What kind of Cisco is this? I am unaware of any Cisco non-networking device (if we assume iSCSI as half-networking) and networking ones should not mess with your TCP (OSI level 4; they ought to deal with IP - OSI level 3). Even if it really does look inside TCP stream it should not limit you to only 16kB! They ought to support RFC1323 and TCP window larger than 64 kB. Zlatko Krastev IT Consultant Lawrie Scott [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 12.11.2002 10:53 Please respond to Lawrie Scott To: [EMAIL PROTECTED] cc: Subject:Re: Poor Performance Hi all Thanx for all the replies some of the tricks have helped a bit. However the TCPWindowsSize of 16 is set as CISCO has a limitation of TCPwindowsize of 16 and whenever we increase it to 63 the server then begins to timeout server requests and no backups happen. Lawrie Scott For: Persetel / Q Vector KZN Company Registration Number: 1993/003683/07 Tel: +27 (0) 31 5609222 Fax: +27 (0) 31 5609495 Cell: +27 (0) 835568488 E-mail: [EMAIL PROTECTED] mailto:lawries;comparexafrica.co.za
Re: Poor Performance
What kind of Cisco is this? I am unaware of any Cisco non-networking device (if we assume iSCSI as half-networking) and networking ones should not mess with your TCP (OSI level 4; they ought to deal with IP - OSI level 3). Even if it really does look inside TCP stream it should not limit you to only 16kB! They ought to support RFC1323 and TCP window larger than 64 kB. Zlatko Krastev IT Consultant Lawrie Scott [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 12.11.2002 10:53 Please respond to Lawrie Scott To: [EMAIL PROTECTED] cc: Subject:Re: Poor Performance Hi all Thanx for all the replies some of the tricks have helped a bit. However the TCPWindowsSize of 16 is set as CISCO has a limitation of TCPwindowsize of 16 and whenever we increase it to 63 the server then begins to timeout server requests and no backups happen. Lawrie Scott For: Persetel / Q Vector KZN Company Registration Number: 1993/003683/07 Tel: +27 (0) 31 5609222 Fax: +27 (0) 31 5609495 Cell: +27 (0) 835568488 E-mail: [EMAIL PROTECTED] mailto:lawries;comparexafrica.co.za
Re: Poor Performance
Hi all Thanx for all the replies some of the tricks have helped a bit. However the TCPWindowsSize of 16 is set as CISCO has a limitation of TCPwindowsize of 16 and whenever we increase it to 63 the server then begins to timeout server requests and no backups happen. Lawrie Scott For: Persetel / Q Vector KZN Company Registration Number: 1993/003683/07 Tel: +27 (0) 31 5609222 Fax: +27 (0) 31 5609495 Cell: +27 (0) 835568488 E-mail: [EMAIL PROTECTED] mailto:lawries;comparexafrica.co.za Notice: This message and any attachments are confidential and intended solely for the addressee. If any have received this message in error, please notify Lawrie Scott at Comparex Africa (Pty) Ltd immediately, telephone number +27 (0) 31 5609222. Any unauthorised use, alteration or dissemination is prohibited. Comparex Africa (Pty) Ltd accepts no liability whatsoever for any loss whether it be direct, indirect or consequential, arising from information made available and actions resulting there from.
Poor Performance
Hi All I am backing up a file server cluster disk to my backup server. Both servers have 1gigabit cards. My server is a Compaq with 2CPU's 1 gig Memory TSM 5.1.1 and to SAN attached Compaq Drive DLT8000 installed in a Compaq TL891 10 Cartridge Library. Journaling is enabled on the file server which has 2gig memory and 4 CPU's. Both servers have teamed Compaq pairs with the 1gigabit card being the primary and a 100mb/s as the failover card. There are some stats at the end. My average Incremental backup is 27Gig and will take anywhere from 2-4 days to complete. Both servers are on a SAN so are the cluster disks, however the backups are done across the LAN at this stage. Both machines run Windows 2000 with the latest service packs. I have had the Compaq guys check the hardware and the network staff look for failures with no success. Any help with this would be greatly appreciated. My DSM.OPT File is as follows:- commmethod TCPIP tcpport 1500 TCPSERVERADDRESS 10.192.100.67 passwordaccess generate clusternodeyes domain all-local tcpwindowsize16 tcpbuff 32 txnbytel 2097152 compression on compressalways no errorlogret 14 schedlogret 14 subdir yes schedmode prompted scrolllines 20 scrollprompt no memoryefficientbackup no * * EXclude and INclude * EXCLUDE.DIR C:\tsm_images EXCLUDE.DIR C:\Program Files\Tivoli EXCLUDE.DIR D:\tsm_images exclude.dir D:\tsmdata EXCLUDE *:\...\TEMPORARY EXCLUDE C:\Documents and Settings\ialbktv\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat.LOG EXCLUDE C:\Documents and Settings\ialbktv\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat EXCLUDE C:\Documents and Settings\ialbktv\ntuser.dat.LOG Exclude C:\Documents and Settings\IALclad\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat.LOG Exclude C:\WINNT\system32\Perflib_Perfdata_4a0.dat exclude *:\...\pagefile.sys exclude *:\...\netlogon.chg exclude *:\...\system32\config\...\* exclude *:\...\ntuser.dat exclude *:\...\ntuser.dat.log exclude *:\...\temp\...\* exclude *:\...\cache\* exclude *:\...\recycler\...\* exclude *:\...\ibmio.com exclude *:\...\ibmdos.com exclude *:\...\msdos.sys exclude *:\...\io.sys exclude.archive *:\...\pagefile.sys exclude.archive *:\...\netlogon.chg exclude.archive *:\...\system32\config\...\* exclude.archive *:\...\ntuser.dat exclude.archive *:\...\ntuser.dat.log exclude.archive *:\...\temp\...\* exclude.archive *:\...\cache\* exclude.archive *:\...\recycler\...\* exclude.archive *:\...\ibmio.com exclude.archive *:\...\ibmdos.com exclude.archive *:\...\msdos.sys exclude.archive *:\...\io.sys include.archive *:\...\*.xls include.archive *:\...\*.doc include.archive *:\...\*.pps include *:\...\*.xls include *:\...\*.doc include *:\...\*.pps Here are some statistics:- DATE_TIME: 2002-11-03 22:54:31.00 MSGNO: 4952 SEVERITY: I MESSAGE: ANE4952I Total number of objects inspected: 156,034 ORIGINATOR: CLIENT NODENAME: ALSFS OWNERNAME: SCHEDNAME: TEST DOMAINNAME: WINDOWS SESSID: 25866 SERVERNAME: ALSBCK DATE_TIME: 2002-11-03 22:54:31.00 MSGNO: 4954 SEVERITY: I MESSAGE: ANE4954I Total number of objects backed up: 155,947 ORIGINATOR: CLIENT NODENAME: ALSFS OWNERNAME: SCHEDNAME: TEST DOMAINNAME: WINDOWS SESSID: 25866 SERVERNAME: ALSBCK DATE_TIME: 2002-11-03 22:54:31.00 MSGNO: 4958 SEVERITY: I MESSAGE: ANE4958I Total number of objects updated: 0 ORIGINATOR: CLIENT NODENAME: ALSFS OWNERNAME: SCHEDNAME: TEST DOMAINNAME: WINDOWS SESSID: 25866 SERVERNAME: ALSBCK DATE_TIME: 2002-11-03 22:54:31.00 MSGNO: 4960 SEVERITY: I MESSAGE: ANE4960I Total number of objects rebound: 0 ORIGINATOR: CLIENT NODENAME: ALSFS OWNERNAME: SCHEDNAME: TEST DOMAINNAME: WINDOWS SESSID: 25866 SERVERNAME: ALSBCK DATE_TIME: 2002-11-03 22:54:31.00 MSGNO: 4957 SEVERITY: I MESSAGE: ANE4957I Total number of objects deleted: 0 ORIGINATOR: CLIENT NODENAME: ALSFS OWNERNAME: SCHEDNAME: TEST DOMAINNAME: WINDOWS SESSID: 25866 SERVERNAME: ALSBCK DATE_TIME: 2002-11-03 22:54:31.00 MSGNO: 4970 SEVERITY: I MESSAGE: ANE4970I Total number of objects expired: 0 ORIGINATOR: CLIENT NODENAME: ALSFS OWNERNAME: SCHEDNAME: TEST DOMAINNAME: WINDOWS SESSID: 25866 SERVERNAME: ALSBCK DATE_TIME: 2002-11-03 22:54:31.00 MSGNO: 4959 SEVERITY: I MESSAGE: ANE4959I Total number of objects failed: 13 ORIGINATOR: CLIENT NODENAME: ALSFS OWNERNAME: SCHEDNAME: TEST DOMAINNAME: WINDOWS SESSID: 25866 SERVERNAME: ALSBCK DATE_TIME: 2002-11-03 22:54:31.00 MSGNO: 4961 SEVERITY: I MESSAGE: ANE4961I Total number of bytes transferred:43.63 GB ORIGINATOR: CLIENT NODENAME: ALSFS OWNERNAME:
AW: Poor Performance with TDP for R/3
Hi Matthias, you should get more! We backup SAP R/3 4.6C directly to tape and get the following statistics. Our TSM Servers is an AIX box (H50) with 1GB memory. Our network is ATM 155Mb and we use 3590E11 drives in a 3494 ATL. BKI0011I: Number of bytes left to be saved: 0 Bytes (0.0%) of 52.053 GB. BKI0022I: Average transmission rate was 71.469 GB/h (20.329 MB/sec). BKI2019I: Compression ratio for backup was 1.70. BKI0021I: Elapsed time: 46 min 55 sec. We use 2 sessions (as we have 2 tape drives) and read 3 files per session in parallel. And we use runlevel compression to remove the binary zeroes of the unused space. Our .UTL file looks like: MAX_SESSIONS 2 MAX_BACK_SESSIONS 2 RL_COMPRESSIONS YES MULTIPLEXING 3 SERVER xy SESSIONS 2 Hope this helps Kind regards Thomas Rupp Vorarlberger Illwerke AG MAIL: [EMAIL PROTECTED] TEL:++43/5574/4991-251 FAX:++43/5574/4991-820-8251 -Ursprüngliche Nachricht- Von: Matthias Feyerabend [SMTP:[EMAIL PROTECTED]] Gesendet am: Freitag, 22. März 2002 14:18 An: [EMAIL PROTECTED] Betreff: Poor Performance with TDP for R/3 We are trying Tivoli Data Protection for R/3 Version 3 Release 2 on a COMPAQ Proliant 5500R, 2 Prozessoren Pentium Pro 200, 1 GB RAM, Datenbank Oracle 8.0.5.1, SAP R/3 45B, The performance is very poor, 500 KB/s, compared to 5 MB/s for local tape and ftp to TSM-Server with 3MB/s. Is there a chance of getting more or is it hopeless ? -- Matthias Feyerabend | [EMAIL PROTECTED] Gesellschaft fuer Schwerionenforschung | phone +49-6159-71-2519 Planckstr. 1| D-62291 Darmstadt | fax +49-6159-71-2519 -- Dieses eMail wurde auf Viren geprueft. Vorarlberger Illwerke AG --
Re: Poor Performance with TDP for R/3
Hi Matthias! Have you changed the MAX_SESSIONS and the SESSIONS parameters in your initSID.utl file? The default is just one session. Also check if you have RL_COMPRESSION set to YES. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Matthias Feyerabend [mailto:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 14:18 To: [EMAIL PROTECTED] Subject: Poor Performance with TDP for R/3 We are trying Tivoli Data Protection for R/3 Version 3 Release 2 on a COMPAQ Proliant 5500R, 2 Prozessoren Pentium Pro 200, 1 GB RAM, Datenbank Oracle 8.0.5.1, SAP R/3 45B, The performance is very poor, 500 KB/s, compared to 5 MB/s for local tape and ftp to TSM-Server with 3MB/s. Is there a chance of getting more or is it hopeless ? -- Matthias Feyerabend | [EMAIL PROTECTED] Gesellschaft fuer Schwerionenforschung | phone +49-6159-71-2519 Planckstr. 1| D-62291 Darmstadt | fax +49-6159-71-2519 ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Poor Performance with TDP for R/3
We are trying Tivoli Data Protection for R/3 Version 3 Release 2 on a COMPAQ Proliant 5500R, 2 Prozessoren Pentium Pro 200, 1 GB RAM, Datenbank Oracle 8.0.5.1, SAP R/3 45B, The performance is very poor, 500 KB/s, compared to 5 MB/s for local tape and ftp to TSM-Server with 3MB/s. Is there a chance of getting more or is it hopeless ? -- Matthias Feyerabend | [EMAIL PROTECTED] Gesellschaft fuer Schwerionenforschung | phone +49-6159-71-2519 Planckstr. 1| D-62291 Darmstadt | fax +49-6159-71-2519
Re: Poor Performance in SAN with TDP for R/3 AIX
I4m using multiplexing 3 and RL Compression, some sessione with two LTO drives and others with one LTO drive. From: Davidson, Becky [EMAIL PROTECTED] Reply-To: ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Poor Performance in SAN with TDP for R/3 AIX Date: Thu, 29 Nov 2001 15:09:16 -0600 How many threads are you using? What multiplexing are you using? Are you using compression? Becky -Original Message- From: Jorge Rodriguez [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 29, 2001 1:40 PM To: [EMAIL PROTECTED] Subject: Poor Performance in SAN with TDP for R/3 AIX Hi... I4m using a SAN with McData switchs, LTO 3584, AIX 4.3.3 TSM Server 4.2, TDP for SAP 3.2.0.6, Storage Agent 4.2. When I use B/A Client the network transfer rate is 90 MB/Sec, but when I use the TDP for SAP the network transfer rate is 20 MB/Sec. What parameters can I set to obtain better performance? Thanks in Advance Jorge Rodriguez Caracas - Venezuela _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Poor Performance in SAN with TDP for R/3 AIX
Hi... I4m using a SAN with McData switchs, LTO 3584, AIX 4.3.3 TSM Server 4.2, TDP for SAP 3.2.0.6, Storage Agent 4.2. When I use B/A Client the network transfer rate is 90 MB/Sec, but when I use the TDP for SAP the network transfer rate is 20 MB/Sec. What parameters can I set to obtain better performance? Thanks in Advance Jorge Rodriguez Caracas - Venezuela _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Re: Poor Performance in SAN with TDP for R/3 AIX
How many threads are you using? What multiplexing are you using? Are you using compression? Becky -Original Message- From: Jorge Rodriguez [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 29, 2001 1:40 PM To: [EMAIL PROTECTED] Subject: Poor Performance in SAN with TDP for R/3 AIX Hi... I4m using a SAN with McData switchs, LTO 3584, AIX 4.3.3 TSM Server 4.2, TDP for SAP 3.2.0.6, Storage Agent 4.2. When I use B/A Client the network transfer rate is 90 MB/Sec, but when I use the TDP for SAP the network transfer rate is 20 MB/Sec. What parameters can I set to obtain better performance? Thanks in Advance Jorge Rodriguez Caracas - Venezuela _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
