Thanks Sung. I did not find any lanfree related issue. As I mentioned
in previous post. I changed 2 parameters:
1. resouceutilization from current 3 to 5
2. tcpwindowsize from current 128 to 63
Now the backup looks very good.
06/23/05 20:26:13 --- SCHEDULEREC STATUS BEGIN
06/23/05 20:26:13 To
Looking at the config, this appears to be lanfree backup client. If the
lanfree is broken, then normally TSM client will default to tcpip over lan.
If this is so, then I do see TSM storage agent version mismatch. From what
I understand, TSM server code and TSM storage agent should match.
Is it po
Hi Richard, TSM Server 5.3 is on AIX, the problem comes from TSM
Client 5.2.3 on HP-UX. But I did read your guide and tried to change 2
parameters:
1. resouceutilization from current 3 to 5
2. tcpwindowsize from current 128 to 63
Let's see how it goes.
Thanks.
On 6/23/05, Richard Sims <[EMAIL PR
ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Matthew
Glanville
Sent: Thursday, June 23, 2005 1:47 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Backup Performance
TSM server 5.3.1.x has a bad bug. I am not sure if you are using that or 5.3.0
But if you are on 5.3.1, you could t
TSM server 5.3.1.x has a bad bug. I am not sure if you are using that or
5.3.0
But if you are on 5.3.1, you could try turning Collocation off for your
destination storage pools.
IBM APAR IC46349
This bug makes TSM 5.3.1 useless for sites backing up more than a few
servers.
Matt G.
William -
See IBM site Technote 1200328, particularly its comments on TCP
window size.
(Those on TSM 5.3 for HP-UX should see Technotes 1193325 and 1206956
regarding
TCPwindowsize and performance. Again, never take defaults.)
Richard Sims
I have a performance issue here, any input would be greatly appreciated.
TSM Server: 5.3 on AIX 5.3
TSM Client: 5.2.3 on HP-UX B.11.11
TSM Storag Agent 5.2.3
Tape Library: IBM 3584 LTO2 with 12 drives
The backup throughput is not good.
06/17/05 06:59:51 Total number of objects inspected: 37
Hi all
Environment:
AIX version 5.2 on IBM pSeries 670 partitioned with 6 processors for
this node DWH (datawarehouse as client for TSM)
TSM Storage agent version 5.2.1.x backing up to TSM server on IBM p630
also running AIX 5.2
Informix version 9.31 64bit
TDP for informix version 5.2
IBM LTO 3584
m: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Dave Canan
Sent: Sunday, February 15, 2004 10:27 AM
To: [EMAIL PROTECTED]
Subject: Re: Solaris backup performance
Ben/Bill,
We have had several performance pmrs in this area recently
after customers have upgraded to AIX 5
day, February 12, 2004 6:28 PM
To: [EMAIL PROTECTED]
Subject: Solaris backup performance
TSM client 5.2.2.0 on a Solaris 7 server, gigabit fibre Ethernet
adapter. TSM Server 5.2.2.1 on AIX 5.2 p630 with fibre gigabit Ethernet.
Different VLAN.
During the backup of this client (actually 4 out of 11 So
TSM GB interface.
My feeling is still an OS problem with the TCP stack when it is
being pushed hard.
Ben
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Bill Boyer
Sent: Thursday, February 12, 2004 6:28 PM
To: [EMAIL PROTECTED]
Subje
: Bill Boyer [mailto:[EMAIL PROTECTED]
Sent: Thu 2/12/2004 19:27
To: [EMAIL PROTECTED]
Cc:
Subject: Solaris backup performance
TSM client 5.2.2.0 on a Solaris 7 server, gigabit fibre Ethernet adapter.
TSM Server 5.2.2.1 on AIX
TSM client 5.2.2.0 on a Solaris 7 server, gigabit fibre Ethernet adapter.
TSM Server 5.2.2.1 on AIX 5.2 p630 with fibre gigabit Ethernet. Different
VLAN.
During the backup of this client (actually 4 out of 11 Solaris clients) the
backup just drags along. Looking at the sessions on the server we se
> Subject: Slow backup performance
Sent by: "ADSM:
Dist Stor
Manager"
<[EMAIL PROTECTED]
T.EDU>
01/29/2004 12:01
You are keeping these files in a SAN?
Why not use SAN own tools (snapshot) for backup?
Juraj
-Ursprüngliche Nachricht-
Von: Dearman, Richard [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 29. Jänner 2004 18:01
An: [EMAIL PROTECTED]
Betreff: Slow backup performance
I backup 10 win2k
I backup 10 win2k servers all with about 150GB of files consisting of 5
million+ files and about 14,000 files change per day per server. With the
current 5.2 tsm client loaded it is taking about 25+ hours to backup. Is
there anyway to speed this up? I tried LVSA and it didn't work because the
ag
Greg,
Go to:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManagerforMail.html
and enter the following in the Search box:
exchange backup performance
There is an article (ID# 1144592) titled:
"Data Protection for Exchange On-line Backup Performance is Slow
Check to see if you have the option 'Zero Out Deleted Database Pages"
checked. If you have this option checked, clear the field (unset it).
Setting this option requires a restart of the Exchange Services. After
restarting Exchange, try the backup again.
At 03:59 PM 12/15/2003 -0700, you wrote:
Hell
Did you try adjusting your buffersize. We have ours set at 1024 and see
pretty good performance.
-Original Message-
From: Redell, Greg S. [mailto:[EMAIL PROTECTED]
Sent: Monday, December 15, 2003 5:59 PM
To: [EMAIL PROTECTED]
Subject: Exchange backup performance
Hello all,
I am
Hello all,
I am trying to see if anyone has any quick suggestions on backing up
Exchange 2000. I am seeing some horrible performance as you can see
from the below stats. This server has never had speedy TDP backups,
BAclient backups normally are in the 10MB/sec range.
The connection is a gigabi
Manager [mailto:[EMAIL PROTECTED]] On Behalf Of
> Eliza Lau
> Sent: Wednesday, September 18, 2002 9:28 AM
> To: [EMAIL PROTECTED]
> Subject: backup performance with db on the Shark ESS
>
> I posted a message a month ago about performance degradation after
> moving
> the d
HACMP
AIX, HACMP, Storage, TSM Consultant
Cell (831) 595-3962
[EMAIL PROTECTED]
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of
Eliza Lau
Sent: Wednesday, September 18, 2002 9:28 AM
To: [EMAIL PROTECTED]
Subject: backup performance with db on the
I posted a message a month ago about performance degradation after moving
the db and the log to the Shark ESS. The problem has been resolved with
help from Paul Seay. Here is a recap:
Moved 32G db and 10G log from attached SCSI non-RAID disks to IBM Shark ESS.
Kept 2 copies of db and log. I wa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On dinsdag, september 3, 2002, at 06:16 , Roger Deschner wrote:
>
> I have had to use the brute force method - "dumb load balancing". That
> is, squeezing the database into the shape I want with DELETE DBVOL.
> Making this work takes careful advance
<[EMAIL PROTECTED]>
Sent by:"ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject:backup performance with db and log on a SAN
I recently moved the 36G TSM database and 10G log from attached SCSI disk
drives to a SAN. Backing the db no
nt: Monday, September 02, 2002 9:17 AM
To: [EMAIL PROTECTED]
Subject: Re: backup performance with db and log on a SAN
On maandag, september 2, 2002, at 01:49 , Daniel Sparrman wrote:
> Hi Eliza
>
> As I understand it, each "tape-HBA" has 3 3590E FC connnected to it.
> The two 21G da
In my experience, "smart load balancing" does not really exist. I
thought I had heard of it, so I went looking on my system to see if it
was doing anything to help. If the Database has plenty of room in it,
and you add a new extent in hope of spreading out the I/O load, that
extent will not be use
Stor Manager" <[EMAIL PROTECTED]>
> 2002-09-02 12:19
> Please respond to "ADSM: Dist Stor Manager"
>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject:Re: backup performance with db and log on a SAN
>
>
> Thanks D
On maandag, september 2, 2002, at 01:49 , Daniel Sparrman wrote:
> Hi Eliza
>
> As I understand it, each "tape-HBA" has 3 3590E FC connnected to it. The
> two 21G database disks, are each connected to it's own HBA?
>
> According to spec sheets, the 3590E FC could handle speed up to 100MB/s
> with
Roger,
Thanks for the detailed analysis. This is what I was planning to do: moved
the db back to attahced SCSI drives. Re-configuring one drawer in the Shark
to non-RAID as another person suggested is out of the question since TSM
is using only a small portion of the Shark. Please read the oth
obil: 070 - 399 27 51
>
>
>
>
> Remco Post <[EMAIL PROTECTED]>
> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
> 2002-09-02 10:48
> Please respond to "ADSM: Dist Stor Manager"
>
>
> To: [EMAIL PROTECTED]
&g
. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180
-Original Message-
From: Roger Deschner [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 01, 2002 2:32 PM
To: [EMAIL PROTECTED]
Subject: Re: backup performance with db and log on a SAN
What a FASCINATING data point!
I think t
Specialist
Naptheon Inc.
757-688-8180
-Original Message-
From: Adolph Kahan [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 02, 2002 10:16 PM
To: [EMAIL PROTECTED]
Subject: Re: backup performance with db and log on a SAN
You are correct the at 3:1 compression you will not do better than
Sent: Monday, September 02, 2002 1:23 PM
To: [EMAIL PROTECTED]
Subject: Re: backup performance with db and log on a SAN
Daniel,
>
> Hi Eliza
>
> As I understand it, each "tape-HBA" has 3 3590E FC connnected to it.
The
> two 21G database disks, are each connected to it
On maandag, september 2, 2002, at 11:26 , Daniel Sparrman wrote:
> Hi
>
> The large disks you are talking about, are you meaning large as 36GB,
> 72GB
> an so on, or are you talking about LUN-sizes?
>
Disk size, 72 GB or so
> In a shark, you can have very large LUN:s, but they will consist
Remco Post <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
2002-09-02 10:48
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject:Re: backup performance with db and log on a
t; Exist i Stockholm AB
> Propellervägen 6B
> 183 62 HÄGERNÄS
> Växel: 08 - 754 98 00
> Mobil: 070 - 399 27 51
>
>
>
>
> Remco Post <[EMAIL PROTECTED]>
> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
> 2002-09-02 10:48
> Pl
On zaterdag, augustus 31, 2002, at 05:18 , Eliza Lau wrote:
> I recently moved the 36G TSM database and 10G log from attached SCSI
> disk
> drives to a SAN. Backing the db now takes twice as long as it used to
> (from 40 minutes to 90 minutes). The old
> attached disk drives are non-RAID and TSM
>
> Paul D. Seay, Jr.
> Technical Specialist
> Naptheon Inc.
> 757-688-8180
>
>
> -Original Message-
> From: Roger Deschner [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 01, 2002 2:32 PM
> To: [EMAIL PROTECTED]
> Subject: Re: backup performance with
Message-
From: Roger Deschner [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 01, 2002 2:32 PM
To: [EMAIL PROTECTED]
Subject: Re: backup performance with db and log on a SAN
What a FASCINATING data point!
I think the problem is simply that it is RAID5. The WDSF/ADSM/TSM/ITSM
Database is
What a FASCINATING data point!
I think the problem is simply that it is RAID5. The WDSF/ADSM/TSM/ITSM
Database is accessed rather randomly during both normal operations, and
during database backup. RAID5 is optimized for sequential I/O
operations. It's great for things like conventional email sys
: Eliza Lau [mailto:[EMAIL PROTECTED]]
Sent: Saturday, August 31, 2002 11:19 AM
To: [EMAIL PROTECTED]
Subject: backup performance with db and log on a SAN
I recently moved the 36G TSM database and 10G log from attached SCSI disk
drives to a SAN. Backing the db now takes twice as long as it used to
I recently moved the 36G TSM database and 10G log from attached SCSI disk
drives to a SAN. Backing the db now takes twice as long as it used to
(from 40 minutes to 90 minutes). The old
attached disk drives are non-RAID and TSM mirrored. The SAN drives are
RAID-5 and TSM mirrored. I know I have
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 16, 2002 7:56 AM
To: [EMAIL PROTECTED]
Subject: windows 2000 cluster backup performance?
Hi all,
Here is an overview of our setup
TSM 4.1.5 server on IBM H80 running AIX 4.3.3
Windows 2000 cluster running active/active config, TSM client 4.2
-Original Message-
From: Piotr Antczak [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 4:33 AM
To: [EMAIL PROTECTED]
Subject: Poor backup performance.
Hi all,
I have very strange behaviour during backup of NetWare 5.1 servers. I have
got TSM server on NT - version 4.1.4. The client
Hi all,
I have very strange behaviour during backup of NetWare 5.1 servers. I have
got TSM server on NT - version 4.1.4. The client version is 4.2.1.0. I try
to backup 100 MB file from SYS: filesystem and everything goes fine (about
3-4 MB/s), if I have only SYS: filesystem mounted. When I mount
AIL PROTECTED]> on 30.10.2001 12:19:27
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject:4.2.0 client backup performance
Hi all,
My scenario
Running a TSM Server 4.2.0 on Win2000 with 3583 Library
My problems is with performances backups of Win2000 Client (4.2.0
Hi all,
My scenario
Running a TSM Server 4.2.0 on Win2000 with 3583 Library
My problems is with performances backups of Win2000 Client (4.2.0).
If the copy destination in backup copy groups is set to TAPEPOOL the
performance is very bad (18 Min. for 800Mb).
If the copy destination in backup c
PROTECTED]
voice: 804-828-4807
Petr Prerost
cc:
Sent by: Subject: Re: Database backup performance
"ADSM: Dist
Stor Manager"
<[EM
kerstorfer
[EMAIL PROTECTED] am 05.07.2001 18:14:35
Bitte antworten an [EMAIL PROTECTED]
An: [EMAIL PROTECTED]
Kopie: (Blindkopie: Gerhard Wolkerstorfer/DEBIS/EDVG/AT)
Thema:Re: Database backup performance
*1*
I have increased it to 9 to see what happens.
This could help in a
Petr Prerost
cc:
Sent by: Subject: Re: Database backup performance
"ADSM: Dist
Stor Manager"
<[EMAIL PROTECTED]
concerned
> since we are currently somewhat real-storage constrained and TSM is
> currently at over 120M WSS, already.
>
> Anyone have any experience with this new option ? Any suggestions/tips
to
> improve the DB backup performance ?
>
> f adsm,q db f=d
> ANR5965I Consol
Zoltan,
Your cache hit percentage is way too low, but that is not going to impact on
your database backup
performance anyway.
I am not sure that you need to increase the number of bufferpool pages.
My database is larger and has a smaller bufferpool with a better cache hit %.
If you are happy
have any experience with this new option ? Any suggestions/tips to
improve the DB backup performance ?
f adsm,q db f=d
ANR5965I Console command: Q DB F=D
Available Space (MB): 17,496
Assigned Capacity (MB): 17,496
Maximum Extension (MB): 0
Maxi
Our db backup stats are below. We do 2 db backups
per day, one to disk and one to tape.
all pages: 11,266,048 (44g)
used pages: 8,387,060 (34g)
disk bkup: 60min - local ESS disk
tape bkup: 60min - 3590 drives
processor: 6k-s7a
We back up 19,591,179 pages in 4 hours. This is an 83GB database, 91%
utilized. Server is an RS/6000 M80. Backup media is DLT 7000
tape. Translates to 5.3MB/s by my calculation. Our incremental backups
usually take 15-30 minutes.
Zoltan,
I have a very large os/390 server. The last full dbb went at a rate of
3.3 million pages/hr, almost 5 times fater than yours.
Since v1 r1 of adsm I haven't found any tricks to speed this up
except to change hardware. My current system is
cpu: 9672-ra6
tape: 9840 running 3590 emulation
Zoltan,
Sorry I forgot to mention, as you are OS390 it will be worth looking at the RMF
statistics
for the period of the database backup. This should show which resource is
causing your backup to run so slow. It could be cpu or possibly disk
contention,
John
Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:(bcc: John Naylor/HAV/SSEG)
Subject: Re: Database backup performance
I guess I should have clarified that the server is on OS/390, not *NIX !!
Thanks for all the responses on how long it takes. Now, how about ways to
im
I guess I should have clarified that the server is on OS/390, not *NIX !!
Thanks for all the responses on how long it takes. Now, how about ways to
improve the speed ?
I am trying a backup to 3590 drives, to see how much of a difference it
makes. So far, there does seem to be a speed difference.
=...)
> > -Original Message-
> > From: Zoltan Forray/AC/VCU [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, June 27, 2001 3:37 PM
> > To: [EMAIL PROTECTED]
> > Subject: Database backup performance
> >
> > Any suggestions on how to improve DB backup performance ?
Doing the math on the quoted database backup sizes and times, plus
my own, shows customers experiencing a db backup data rate of
3 - 4 MB/sec. That is well below the capabilities of the disk and
tape technology in use, and points to the often-criticized TSM
database system being the drag on perfo
Our DB is 13.5GB, 65% utilized. Full backup in 30 minutes to IBM 3575 library with
C-XL drives.
TSM 3.7.4.0 on AIX 4.3.3, IBM RS6000 F50.
David Longo
>>> [EMAIL PROTECTED] 06/27/01 09:37AM >>>
Any suggestions on how to improve DB backup performance ?
Doing a FULL DB backu
Our DB is 21 GB, 85% Utilized. Backup time is 34 minutes.
Running TSM 3.7.4 on Windows 2000. Backup to DLT 7000 tape.
This translates to about 9 MB/sec.
Tim Rushforth
City of Winnipeg
>Doing a FULL DB backup of our 15GB ADSM (yes, not TSM YET. Hoping to
convert to 4.1.3 RSN !!) server, sometimes takes 4-hours.
>Since I read a previous message about someone having a 52GB DB, I was
wondering how long it takes to backup that much DB since my meager DB takes
so long ?
About 3
-
> From: Zoltan Forray/AC/VCU [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, June 27, 2001 3:37 PM
> To: [EMAIL PROTECTED]
> Subject: Database backup performance
>
> Any suggestions on how to improve DB backup performance ?
>
> Doing a FULL DB backup of our 15GB
Any suggestions on how to improve DB backup performance ?
Doing a FULL DB backup of our 15GB ADSM (yes, not TSM YET. Hoping to
convert to 4.1.3 RSN !!) server, sometimes takes 4-hours.
Since I read a previous message about someone having a 52GB DB, I was
wondering how long it takes to backup
Hi all,
We did a selective backup to test performance. The environment is:
TSM server 3.7.3.0
SUN TSM Client 3.7.2.0
Network 100Mb Ethernet
Test data size 17MB.
Here is the result:
Final Detailed Instrumentation statistics
Elapsed time: 7.873 sec
Section
Hi there,
first of all sorry for the long append but I need to explain my problem in
detail.
I was trying to optimize our backup performance for a particular node, so I got
a look at
INSTR_CLIENT_DETAIL trace output.
Server is ADSM 3.1.2.50 on OS/390 V2R6
Client is USS 3.1.0.5
Commethod is TCPIP
We have one TSM server that does nothing except UDB backups. Our
configuration
is sp nodes (both tsm server and udb clients) with 3590 B drives, tsm 4.1.2.0
on aix
4.3.3, udb eee 7.1.
18 megs/sec/drive is what we see for udb data backups ...using using 4 drives
we get
an aggregate total of 72 m
101 - 170 of 170 matches
Mail list logo
