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 zfor...@vcu.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." <nbstr...@leggmason.com> To: ADSM-L@VM.MARIST.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@VM.MARIST.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:ads...@vm.marist.edu] On Behalf Of Zoltan Forray/AC/VCU Sent: Tuesday, October 19, 2010 9:15 AM To: ADSM-L@VM.MARIST.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 zfor...@vcu.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.