>> On Mon, 3 May 2010 13:55:52 +1000, Mehdi Salehi
>> 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,
and that's if
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
cc
Manager"
Re: mediawait during backup to disk
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
wrote:
Smaller
On Mon, May 3, 2010 at 3:48 PM, Howard Coles
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
> RAM and processor power you
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
- 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 p
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 TSM
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
>> On Fri, 30 Apr 2010 14:07:56 -0400, Keith Arbogast
>> 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 at the extre
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
To:
ADSM-L@VM.MARIST.EDU
Date:
04/30/2010 08:09 AM
Subject:
[ADSM-L] mediawait during backup to
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
affected
ADSM: Dist 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 t
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 e
>> On Fri, 30 Apr 2010 11:07:35 -0400, Keith Arbogast
>> 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. So there's some
15 matches
Mail list logo