We are currently on tsm v5.1 also, and I have seen the "sleep" that you
describe, although not nearly as bad. Up to a couple months ago, the db
backup for one of our TSM server was taking 4-5 hours (140gb). From when
the start db backup command was issues until the process showed up took
about 5 min. Part of this was waiting for a virtual volume mount, but not
all. I never figured out want TSM was doing, but It looked like it was
performing highly random access around the db preparing for the backup.
Since we moved the db and log to a new disk system and heavily striped it,
we've cut our backup time to 1hr. There is still a wait for the virtual
volume mount, but nothing like it was before.
Along with what others have recommended, I'd suggest talking with the
storage admins about the layout on the backend of the Symm. They need to
look at the layout of the 4 TSM luns on the backend, what else is on those
spindles, load, striping, striped or concatinated meta's. To me it sounds
like a disk system severely short on spindles and striping.
Rick
Paul van Dongen
<Paul@VANGUARD-IT To: ADSM-L AT VM.MARIST
DOT EDU
.COM.BR> cc:
Sent by: "ADSM: Subject: Very slow DB backups
Dist Stor
Manager"
<[email protected]
.EDU>
07/01/2005 07:37
AM
Please respond to
"ADSM: Dist Stor
Manager"
Hello All,
I was called to examine a TSM server in order to make some suggestions
to improve performance. Upon arrival, I found out a not-so-standard
configuration:
TSM 5.1.6.4 on HP-UX 11
DB: 208 GB split on 208(!) volumes of 1GB each spread on 4 LUNs on an EMC
box (95% in use)
Log: 10 volumes of 1GB each, all on the same EMC LUN
Diskpool: 101 volumes of 1GB each, all on the same EMC LUN
I know that splitting this server should be the best solution, and there
are other factors contributing to this big DB size, but I will stay away
from this for while.
The first I noticed is that there are two full DB backups being executed
each day. They go to a LTO device class, and are taking some 3 to 4 hours
to complete, including a stange 5 to 10 minute "sleep" between the backup
command being issued and the actual start of the process. I tried to
minimize this by setting the log to rollforward and trying to take a
incremental backup. To my surprise, the triggered incremental (log became
70% full) started, with the same delay described above, but began to crawl,
at 8000 pages per MINUTE. It would give me almost 4 hours to copy the 7 or
so GB!! Naturally, I went back to the fulls until I found out what could be
the problem.
I am trying to talk to the admin of this server to upgrade to 5.2 or 5.3
and to review their disk config, but would like to hear from you if someone
has been trough something alike, and of course the line of action that was
taken.
Thanks to all,
Paul
-----------------------------------------
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.
|
