ADSM-L

Re: [ADSM-L] Lousy performance on new 6.2.1.1 server with SAN/FILEDEVCLASS storage

2010-10-20 02:05:31
Subject: Re: [ADSM-L] Lousy performance on new 6.2.1.1 server with SAN/FILEDEVCLASS storage
From: Remco Post <r.post AT PLCS DOT NL>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 20 Oct 2010 08:04:25 +0200
Hi Zoltan,

even with devtype file, using pre-formatted volumes is recommended.

On 19 okt 2010, at 21:41, Zoltan Forray/AC/VCU wrote:

> Neil,
>
> Thanks for the info.  I have passed this on to my SAN guys since I know
> nothing about this aspect of the configuration nor if we can make these
> tweaks.
>
> I am still wondering if I should go back to the traditional fixed size,
> pre-formatted volumes.  Everyone says filedevclass is supposed to be
> faster and better so I thought I would give it a try.
> 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.