On 21 okt 2010, at 20:58, Zoltan Forray/AC/VCU wrote:

> Thanks for the hint.......using Google is great (which I do), but if you
> don't have a clue what to look for........like a dictionary--you have to
> have some kind of clue/general idea how a word is spelled to be able to
> look it up  ;----)
> 

you're so right.

> I did find a /sys/block/emcpowerb/queue/nr_requests file with 128 in it.
> 

which sounds ok... if that's the queue depth, which I'm guessing it is. And 128 
outstanding requests.... you'll never need more. I've recently increased the 
queue depth on the HBA while doing some performance testing, and have not 
noticed any major impact with the server and the box on the same switch. I 
wouldn't bother with that unless some support guy explicitly tells you to do so.

> 
> 
> From:
> Remco Post <r.post AT PLCS DOT NL>
> To:
> ADSM-L AT VM.MARIST DOT EDU
> Date:
> 10/21/2010 02:47 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>
> 
> 
> 
> Hi all,
> 
> YMMV, I've really never played with these, but check
> /sys/block/sdX/queue/nr_requests and some other files in that dir
> 
> ow BTW, google is your friend ;-)
> 
> On 21 okt 2010, at 19:38, Zoltan Forray/AC/VCU wrote:
> 
>> This is RedHat Linux 5.5
>> 
>> 
>> 
>> From:
>> Remco Post <r.post AT PLCS DOT NL>
>> To:
>> ADSM-L AT VM.MARIST DOT EDU
>> Date:
>> 10/21/2010 01:24 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>
>> 
>> 
>> 
>> for AIX:
>> 
>> lsattr -l hdiskX -> look foor the queue_depth field values between 20
> and
>> 64 make sense, 128 in some extreme cases
>> chdev -l hdiskX -a queue_depth=Y (but only if the vg is off-line)
>> 
>> I found that some drives only support a queue_depth of 1... in that
> case,
>> you found your bottleneck.
>> 
>> On 21 okt 2010, at 18:57, Zoltan Forray/AC/VCU wrote:
>> 
>>> 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.
>> 
>> --
>> Met vriendelijke groeten/Kind Regards,
>> 
>> Remco Post
>> r.post AT plcs DOT nl
>> +31 6 248 21 622
> 
> --
> Met vriendelijke groeten/Kind Regards,
> 
> Remco Post
> r.post AT plcs DOT nl
> +31 6 248 21 622

-- 
Met vriendelijke groeten/Kind Regards,

Remco Post
r.post AT plcs DOT nl
+31 6 248 21 622