Paul (or anyone who knows),
If Vin has the logging mode set to rollforward, does that impact
performance? I only suggest this because I have had a nagging slowdown
in some operations and the only change I can really identify is that we
switched from normal to rollforward logging. Just a wild guess.
-----Original Message-----
From: seay_pd AT NAPTHEON DOT COM
Sent: Wednesday, October 30, 2002 10:36 PM
To: NAPTHEON.COM.seay_pd; VM.MARIST.EDU;.ADSM-L
Subject: Re: HELP! Faster Restore than Backups over Gigabit?
You have lots of RAM, but what is your bufferpool size. For this size
of machine memory, I would use at least 256MB for the bufferpool size.
Also beef up the logpool size as well. Your TSM DB and log are very
small. Do a Q DB F=D command and see what your database hit percentage
is. If it is less than 98 percent you need to increase the bufferpool.
Did you TSM mirror the Database and Log? If so, it is probably useless
because you are already running protected disk. Remember, on RAID 1 you
still have to write all data twice and on read back both drives can be
used as a source if the RAID card is smart enough to do that.
I am betting that you are overrunning the RAID card during the backup.
Are the RAID 1 mirror volumes on the same physical SCSI bus as the
primaries? That could be the issue as well.
Hope this helps.
Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180
-----Original Message-----
From: Vin Yam [mailto:vyam AT QBCT DOT COM]
Sent: Wednesday, October 30, 2002 11:14 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: HELP! Faster Restore than Backups over Gigabit?
Hi,
Our backups are set for an absolute serialization. We backup and
restore the same number of files and the same amount of data 42 GB. The
TSM server is configured in a RAID 1E0 with a ServeRAID 4Mx adapter.
The client is using a RAID 1. We are going straight to disk since our
diskpool is 150 GB. We've tried formatting the partition that the
diskpool is on in 64k blocks, but it hasn't proved much help.
Is there a case where the TSM DB can be TOO large? Our TSM DB volume is
1 GB in size and our recovery log is 250 MB in size. We have 4 GB of
RAM on the TSM server, so we didn't consider this to be a problem.
Thanks for any help. Please email me if you need more information.
-Vin
vyam AT qbct DOT com
-----Original Message-----
Forum: ADSM.ORG - ADSM / TSM Mailing List Archive
Date: Oct 30, 00:08
From: Seay, Paul <seay_pd AT NAPTHEON DOT COM>
Actually, the 2048 TCPWINDOWSIZE is not supported in NT to my knowledge.
It is supported in W2K at SP1 or 2, cannot remember, with a registry
hack. Someone else will have to give the particulars on that.
Be careful comparing restores to backups. Depending on what numbers you
are using, you may get the wrong conclusions. Make sure it is the same
files backed up that were restored. Also, look at where your backup is
going to on your server. If it is going to RAID-5 storage pools, that
is it. The write penalty on the RAID-5 Array is the cause of the backup
delay. If you are going directly to tape, I do not know what the issue
is without a lot more information.
Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180
-----Original Message-----
From: Vin Yam [mailto:vyam AT QBCT DOT COM]
Sent: Tuesday, October 29, 2002 7:16 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: HELP! Faster Restore than Backups over Gigabit?
Hi,
We just installed Gigabit fiber NICs and an isolated gigabit fiber
switch. Our restores have increased dramatically from 31.81 GB/hr (8.84
MB/s) to 56 GB/hr (15.6 MB/s). The backups are still around 35.5 GB/hr
(9.8 MB/s). The TSM server is very powerful (NT 4.0 SP6a Dual 1.8 Ghz
P4 w/ 4GB RAM, 150 GB RAID array) and the clients are (Netware 4.2 Quad
XEON P3 w/ 4 GB RAM). (We've tried changing the TCPWindow Size in our
dsmserv.opt from 63 to 2048 with no effect) We're running TSM 5.1.1.4
server and TSM 4.2.3 netware
client. Any
ideas? Please email me direct if you have any suggestions or need more
information. Thanks.
DSM.OPT settings
** TSM TWEAKS **
COMPRESSION NO
LARGECOMMBUFFERS YES
MEMORYEFFICIENTBACKUP NO
PROCESSOR 20
RESOURCEUTILIZATION 10
TXNB 2097152
TCPB 32
TCPNodelay YES
TCPWindowsize 64
** TSM TWEAKS **
managedservices schedule webclient
schedmode prompted
-Vin
vyam AT qbct DOT com
|
