TDP for Exchange 6.3 client SPEED ISSUES! (SLOW!!)

[rbnllobertk]

We've recently introduced a number of WIN2k8(r2) servers running Exchange2k10 into our TSM environment. They're running the TDP6.3 client. This is the first time we've had to use this "newer" client version, utilizing the VSS backup and such. Since we started using this newer version of TDP our backups are running a LOT slower than they should, and definitely a LOT slower than they did on the v5.5 TDP client. Any thoughts? Anything we can do to the dsm.sys? Its becoming a serious issue in our environment as we're running out of enough hours in the day to get them backed up! thanks in advance! -Robert

 

[ja954]

We see a performance hit when the Exchange integrity check runs before the backup. Every third party backup vendor is suggested to run this check as it reads every page of the Exchange data store to insure data is good for a backup. You can skip this check with the /SKIPINTEGERITYCHECK option. This is not recomended by Microsoft.
You may not be having the same issue but in general we see the actual backups (data flowing to the TSM server) running faster then with pervious versions.
Currently our command for doing a backup looks like this:
tdpexcc back DB022,DB043,DB064,DB085,DB121 full /EXCLUDEDAGACT /SKIPINTEGRITYCHECK /LOGF=c:\tsm\logs\%cdate%\%cdate%_TDPEXC.LOG

 

[simonpie]

Following IBM's documentation, the option /SKIPINTEGRITYCHECK works only for COPY backup type not Full backup type.

https://publib.boulder.ibm.com/info...ex.jsp?topic=/com.ibm.itsmfm.doc/dpexc108.htm

 

[ja954]

Following IBM's documentation, the option /SKIPINTEGRITYCHECK works only for COPY backup type not Full backup type.

https://publib.boulder.ibm.com/info...ex.jsp?topic=/com.ibm.itsmfm.doc/dpexc108.htm

You are using the TDP version 5.5 options (referenced in you link). For TDP 6.3.x you can skip the integrity check in full backup mode.

 

[simonpie]

Darn google which always bring me to obsolete pages for TSM. I cannot find the doc for 6.3, nor 6.4 which we have. But the doc for 7.1 seems to agree with you. Thanks, I will try it tonight anyway.

 

[BrianV]

It's that damn ESEUTIL that Exchange uses. Microsoft will recommend skipping the integrity check as long as you have DAG's. You can also add the /PREFERDAGPASSIVE switch to exclude all passive copies.

 

[simonpie]

Hi, we have the preferdagpassive switch. We tried the skipintegrety check switch but the backup still takes 9 hours for about 1.3 TB. Something is clearly wrong. Any idea what I could investigate ?

Here is the command we run

TDPEXCC BACKUP DB1,DB2,DB3 FULL /MINIMUMBACKUPINTERVAL=60 /PREFERDAGPASSIVE /SKIPINTEGRITYCHECK

Here is the output of tdpexcc q tdp

IBM Tivoli Storage Manager for Mail:
Data Protection for Microsoft Exchange Server
Version 6, Release 4, Level 0.0
(C) Copyright IBM Corporation 1998, 2012. All rights reserved.

Data Protection for Exchange Preferences
----------------------------------------

BACKUPDESTination................... TSM
BACKUPMETHod........................ VSS
CLIENTAccessserver..................
DAGNODe............................. MyDagNode
DATEformat ......................... 3
LANGuage ........................... ENU
LOCALDSMAgentnode................... MyNodeName
LOGFile ............................ c:\pathtologs\tdpexc.log
LOGPrune ........................... 60
MOUNTWait .......................... Yes
NUMberformat ....................... 1
REMOTEDSMAgentnode..................
TEMPDBRestorepath...................
TEMPLOGRestorepath..................
TIMEformat ......................... 1
IMPORTVSSSNAPSHOTSONLYWhenneeded.... No

The operation completed successfully. (rc = 0)

 

[BrianV]

Well, the fact that this started happening when you installed 6.3 is strange. We moved from 6.1 to 6.4 and didn't encounter performance issues and didn't have to make any changes to our script or add any additional options. Have you opened a ticket with support?

In the meantime, how many mount points have you allowed on the Exchange node, DAG node, and local dsmagent node? Also, what do you have as your RESOURCEUTILIZATION in the dsm.opt of the local dsmagent node?

 

[simonpie]

Well, the fact that this started happening when you installed 6.3 is strange. We moved from 6.1 to 6.4 and didn't encounter performance issues and didn't have to make any changes to our script or add any additional options. Have you opened a ticket with support?

In the meantime, how many mount points have you allowed on the Exchange node, DAG node, and local dsmagent node? Also, what do you have as your RESOURCEUTILIZATION in the dsm.opt of the local dsmagent node?

The problem did not happened when we installed 6.3. It just happened gradually as we started migrating exchange 2003 to 2010.
We have nothing for resourceutilization, but I was planning trying a fairly high value tonight, probably 10 as this is a fairly powerful machine.

The maximum mount point is 1, but we do our backup to disk and then destage to tape.

 

[Tiger22]

Are you running your new Exchange servers within a clustered environment?

 

[simonpie]

Its a DAG. I have tried the RessourceUtilisation parameter (value of 10). No change, still almost 10hours. Most parameters are set to default parameters.

dsm.opt for baclients :

NODENAME Node-name
PASSWORDACCESS GENERATE
TCPSERVERADDRESS Server-Name
TCPCADADDRESS 10.99.212.210
AUTODEPLOY NOREBOOT
TCPCLIENTADDRESS DNS-name
SCHEDMODE PROMPTED

DATEFORMAT 3
SCHEDLOGRETENTION 30
SchedLogName some-path
ErrorLogName some-path
ErrorLogRetention 30
RESOURCEUTILIZATION 10

TCPPort 1500

exclude.dir *:\some-directory

dsm.opt for tdpe

NODename EXCH-Node-Name
PASSWORDAccess generate
TCPServeraddress Server-Name
TCPPort 1500
HTTPport 1582

and some basic server settings :

tsm: Server-Name>q option max*

Server Option Option Setting
------------------------- -----------------------------------
MaxSessions 200

tsm: Server-Name>q option res*

Server Option Option Setting
------------------------- -----------------------------------
RestoreInterval 1,440
Resource Timeout 60

tsm: Server-Name>q option tcp*

Server Option Option Setting
----------------- --------------------
TcpPort 1500
TcpAdminport 1500
TCPWindowsize 64512
TCPNoDelay Yes

There are way under 200 sessions most of the time. At peak hour, the server will receiver 750 GB per hour (for about one hour). Yet this backup will take around 10 hours for 625 GB.