There should be queue depth settings for individual disks and for the
HBA on the server - not on the Array. The sum of the Disk settings
should not exceed the setting for the HBA.
By EMC voodoo I meant the EMC management application that allows you to
monitor the performance of the array - I'm not sure what it's proper
name is.
As Remco pointed out check with the EMC folks and your HBA vendor and OS
support to determine queue depth limitations. Seems like I ran across a
combination for AIX or Solaris attached to either an older FastT or
NetApp that defaulted to a depth of 1 and required a firmware update to
fix.
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Thursday, October 21, 2010 12:58 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Lousy performance on new 6.2.1.1 server with
SAN/FILEDEVCLASS storage
In reference to these recommendations, this is what one of my SAN folks
said:
If "increasing the queue depth for the individual disks" is something
you
can do on a CLARiiON, it's not something I'm familiar with. On the HBA
(and if you can), you would do that from the host side (like with
SanSurfer for Qlogic HBAs).
I have no idea what he might be referring to with "EMC voodoo
application".
"iostat/vmstat" are unix host utilities.
Each of the two LUNs is spread out over 7 disks. The 2 RAID Groups and
the enclosure they are in are dedicated to Tivoli.
I've seen some references to using lots of smaller LUNs rather than a
few
big ones. You have 2 5.5TB LUNs now. We can try splitting each of
those
into 10-12 smaller LUNs.
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html
From:
"Strand, Neil B." <NBStrand AT LEGGMASON DOT COM>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
10/19/2010 01:50 PM
Subject:
Re: [ADSM-L] Lousy performance on new 6.2.1.1 server with
SAN/FILEDEVCLASS
storage
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Zoltan,
You may need to increase the queue depth for the individual disks
and/or the HBA attached to the disks.
Monitor both the server (iostat/vmstat) and the storage (EMC voodoo
application) for latency and compare the results for consistency. You
may need to adjust the striping of your logical LUNs on the storage. I
have observed serious performance degradation on an older IBM ESS simply
because the logical volumes were created on a single SSA rather than
spread across the entire set of disks.
Cheers,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Tuesday, October 19, 2010 9:15 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Lousy performance on new 6.2.1.1 server with
SAN/FILEDEVCLASS storage
Now that I have ventured into new territory with this new server (Linux
6.2.1.1), I am experiencing terrible performance when it comes to moving
data from disk (FILEDEVCLASS on EMC/SAN storage) vs my other 6.1 and 5.5
servers.
With the server doing nothing but migrating data from this SAN based
stgpool to TS1130 tape, I am seeing roughly 700GB being moved in a
12-hour
period. On my other, internal disk based TSM servers, I move
multiple-terabytes per day/24-hours.
So, where should I focus on why this is so slow? Is it because I am
using
SAN storage? How about the FILEDEVCLASS vs fixed, pre-formatted volumes
(like every other server is using)?
Or is this normal? If it is, I am in for some serious problems. One of
these servers is expected to replace an existing 5.5 server that
processes
20TB+ of backups, per week (no, I can not go straight to tape due to the
type of backups being performed).
Suggestions? Thoughts?
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html
IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason
therefore recommends that you do not send any confidential or sensitive
information to us via electronic mail, including social security
numbers,
account numbers, or personal identification numbers. Delivery, and or
timely delivery of Internet mail is not guaranteed. Legg Mason therefore
recommends that you do not send time sensitive
or action-oriented messages to us via electronic mail.
This message is intended for the addressee only and may contain
privileged
or confidential information. Unless you are the intended recipient, you
may not use, copy or disclose to anyone any information contained in
this
message. If you have received this message in error, please notify the
author by replying to this message and then kindly delete the message.
Thank you.
IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason
therefore recommends that you do not send any confidential or sensitive
information to us via electronic mail, including social security numbers,
account numbers, or personal identification numbers. Delivery, and or timely
delivery of Internet mail is not guaranteed. Legg Mason therefore recommends
that you do not send time sensitive
or action-oriented messages to us via electronic mail.
This message is intended for the addressee only and may contain privileged or
confidential information. Unless you are the intended recipient, you may not
use, copy or disclose to anyone any information contained in this message. If
you have received this message in error, please notify the author by replying
to this message and then kindly delete the message. Thank you.
|
