We use EMC storage.  We use the following settings on our AIX servers
which are specified by EMC in their host attachment guides.

# hba settings
chdev -l fcsX -a num_cmd_elems=2048        # hba queue depth
chdev -l fcsX -a max_xfer_size=0x1000000   # max transfer size

# scsi protocol adapter settings
chdev -l fscsiX -a fc_err_recov=fast_fail   # fail I/O's fast
chdev -l fscsiX -a dyntrk=yes               # allow aix to track binding
changes

# Symmetrix/DMX hdisk
chdev -l $i -a queue_depth=128    # hdisk queue depth

# Clariion
chdev -l $i -a queue_depth=32    # hdisk queue depth


Please note - just maxing out the queue depth on the host can cause
problems.  The storage system port also has a queue depth.  If your
storage system ports are shared across multiple server then you
don't want the total queue depth across the servers to overflow the
queue depth on the storage port. In other words, you don't want a
server to fire a I/O to a storage system only to have the storage
system send back an error saying it's queue is full, requiring a
retry on the I/O - this is a major performance hit.  How do you do
this?  In all practical sence . . .you don't.  Find out what your
vendor recomemds and use that.

On AIX you can tell if you have hit IT'S hdisk queues are full
in "iostat -Dl", althought this tells you nothing about the
storage system or HBA.






                                                                           
             Michael Green                                                 
             <mishagreen@GMAIL                                             
             .COM>                                                      To 
             Sent by: "ADSM:           ADSM-L AT VM.MARIST DOT EDU              
  
             Dist Stor                                                  cc 
             Manager"                                                      
             <[email protected]                                     Subject 
             .EDU>                     Re: mediawait during backup to disk 
                                                                           
                                                                           
             05/03/2010 09:26                                              
             AM                                                            
                                                                           
                                                                           
             Please respond to                                             
             "ADSM: Dist Stor                                              
                 Manager"                                                  
             <[email protected]                                             
                   .EDU>                                                   
                                                                           
                                                                           




On Mon, May 3, 2010 at 3:48 PM, Howard Coles
<Howard.Coles AT ardenthealth DOT 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
> RAM and processor power you have as well.  The Single LUN shouldn't be a
> problem as long as you have a good queue depth, but I would definitely
> break up the pool into multiple volumes.

Have you actually configured queue depth (at HBA level I guess) to
anything other than default? If yes, would you please share the
details with us?


-----------------------------------------
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.