November 8, 2012 at 8:51 am
forgive me if this is a dumb question.
the san guys are very unhelpful where i currently work and i would like to know how to find out myself but have limited knowledge (& access to certain tools/info) here.
so i'm looking at disk management on my server, there is one scsi disk device listed. this has 7 partitions. how do i know how many physical disks this equates to?
also, how do i know what raid config these are configured with?
i want to know what to divide my avg disk queue length by and ultimately find out if disk io is in the frame for some of our app performance issues on this server.
thank you
November 8, 2012 at 8:59 am
Ignore avg disk queue length 'thresholds' completely. It's extremely hard to interpret with all that's between a server and its disks these days. Trend it, look for changes from normal (normal for your server), don't compare it against some threshold from some whitepaper.
Much more meaningful metrics are avg disk sec/read and avg disk sec/write.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
November 8, 2012 at 9:09 am
Ok, thanks for the advice. I'll do as you suggest and plod on with the other metrics / baseline comparisons.
Would still be interested in the answers wrt physical drives & raid config. I've tried all the Powershell commands that look likely and am afraid there may be no other way than asking the unapproachable san guy ...
this performance stuff is very interesting but having never got seriously stuck into it before i have to admit it's making me boz eyed now.
November 8, 2012 at 11:28 am
snomad (11/8/2012)
Ok, thanks for the advice. I'll do as you suggest and plod on with the other metrics / baseline comparisons.Would still be interested in the answers wrt physical drives & raid config. I've tried all the Powershell commands that look likely and am afraid there may be no other way than asking the unapproachable san guy ...
this performance stuff is very interesting but having never got seriously stuck into it before i have to admit it's making me boz eyed now.
Why do you suspect there are performance problems with the SAN?
Most of the supposed hardware related performance problems that I've run up against aren't really hardware problems. Case in point... the went from a 4 CPU server and a "slow" SAN to a (at the time) state of the art server with 16 CPU's and an absolute killer of a SAN. Everyone was expecting every 1 to 8 hour job to run in minutes.
It didn't happen.
The problem is that the "crap" code they had written was still crap code. Sure, it improved performance some but the 1 to 8 hour jobs were still taking 45 minutes to 6 hours to run. One of the jobs was a 24+ hour job that would frequently fail. The very new (and very expensive) hardware and all of the heartache in migrating all that data to the new system didn't do a thing for it. I spent 2 days rewritting the code for that batch job and got it down to 11 minutes flat. That's about 130 times (13,000%) faster. That was 4 years ago and, to this day, it hasn't failed yet.
Try getting hardware that will give you run times that are 130 times faster like that. It's just not going to happen.
Performance is in the code. The best hardware in the world won't fix the performance problems of "crap" code.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2012 at 11:55 am
snomad (11/8/2012)
Would still be interested in the answers wrt physical drives & raid config. I've tried all the Powershell commands that look likely and am afraid there may be no other way than asking the unapproachable san guy ...
Chances are you will not be able to "see" how your SAN is implementing storage from Windows. Presented storage is "just another disk" to Windows and many SANs today virtualize the storage to increase IOPs so you never really know what is behind that disk. Baseline your server and then work with your storage team if you see performance dropoffs and cannot attribute it to application activity, e.g. if you think the SAN is overloaded or there were disk failures that are hampering performance.
Yes, you need to make sure your hardware is sized to handle your workload, properly configured and have monitoring in place to recognize hardware failures in realtime but focusing on enhancing performance by improving application design and tuning your database code will give you a much better chance for maintaining a healthy application.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply