Smaller storage pool volumes and more of them. Then TSM only has to
open and use what it needs at the time, and more processes can be run
successfully at the same time. Of course this all depends on how much
RAM and processor power you have as well. The Single LUN shouldn't be a
problem as long
On Mon, May 3, 2010 at 3:48 PM, Howard Coles
howard.co...@ardenthealth.com wrote:
Smaller storage pool volumes and more of them. Then TSM only has to
open and use what it needs at the time, and more processes can be run
successfully at the same time. Of course this all depends on how much
I'm fairly sure I remember an IBM recommendation that suggested you
should try to have broadly as many individual disk volumes defined in
a stgpool as you will have concurrent client sessions writing to that
stgpool.
David McClelland
London
On 3 May 2010, at 13:48, Howard Coles
cc
Manager
ads...@vm.marist Subject
.EDU Re: mediawait during backup to disk
The server has 16 processors and 128 GB ram.
From Michael Green: Have you actually configured queue depth...?
No, we haven't. It is set at the default of '16'. It can be as high as
256. The HBA's are HP FC1242SR, which are re-branded QLogic QLE2462.
All best wishes,
Keith
On Mon, 3 May 2010 13:55:52 +1000, Mehdi Salehi ezzo...@googlemail.com
said:
Here is my question from the group:
Which one performs better?
a- One big TSM volume on a 2TB LUN
b- More than one TSM volumes on a 2TB LUN
If it's SATA RAID5 underneath, I'd be scared to do more than 4 or so,
Allen,
Thank you for that bit of advice. It was just what I needed. The
question of how small to make the TSM volumes was on my mind.
Our disk pools are on Hitachi AMS2300 SAS drives. We have use of six
2 TB LUNs. One volume group is defined per LUN, then 14 TSM volumes
per VG at 125 GB. The
- One point is that you gain virtually nothing by 6 volume groups. You can
put the six LUNs in a single VG, no performance difference I believe.
- Have you tuned the queue_depth of the LUNs based on AMS documentation.
Check it by lsattr -El hdiskX
Here is my question from the group:
Which one
On Fri, 30 Apr 2010 11:07:35 -0400, Keith Arbogast warbo...@indiana.edu
said:
What does it mean when a node incurs mediawait during a backup to
disk?
It means that the process was blocking on disk writes.
Your disk (usually) can't write as fast as your various networks can
pass you data.
Keith,
You could mitigate this somewhat by creating more disk storage pool
volumes, and spreading them across more physical disks.
I don't entirely agree with Allen that your disk pool is going to be
slower than your incoming networks. It is certainly possible to build a
disk storage pool
Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
John D. Schneider
Sent: Friday, April 30, 2010 10:33 AM
To: ADSM-L@vm.marist.edu
Subject: Re: mediawait during backup to disk
Keith,
You could mitigate this somewhat by creating more disk storage pool
volumes, and spreading them across more
Thanks to all who offered advice. I may have been taking the book
definition of mediawait too literally -- as pertaining to removable
volumes, not disk.
I was able to correlate the MediaWait condition showed by TSMManager
with dsmaccnt.log records for the nodes last night. 20 nodes were
Are these windows clients? Is the dirmc (directory management class)
pointed to disk or tape?
You may have windows clients queueing up to write their directories to
tape.
[RC]
From:
Keith Arbogast warbo...@indiana.edu
To:
ADSM-L@VM.MARIST.EDU
Date:
04/30/2010 08:09 AM
Subject:
[ADSM-L]
On Fri, 30 Apr 2010 14:07:56 -0400, Keith Arbogast warbo...@indiana.edu
said:
I'll redefine smaller, more plentiful TSM volumes for this pool, and
see if that keeps the sand out of my socks.
Heh. :) Good luck.
Don't go nuts with the smaller direction. There are major
performance problems
Robert,
Thank you. It is a mix of Windows and Linux clients. And, we impose
a cloptset on all clients that includes a dirmc that writes to disk.
Best wishes,
Keith
15 matches
Mail list logo
