Re: Choosing the proper disk setup. I need help and advice.
From: Scott Davis (sdavis_at_esctech.ca)
Date: 09/26/04
- Next message: Scott Davis: "Re: Forest Trusts are backwards?"
- Previous message: Timothy Drouillard: "Re: NT PDC can no longer administer users it it's own domain but can in others."
- In reply to: Guadala Harry: "Re: Choosing the proper disk setup. I need help and advice."
- Next in thread: Guadala Harry: "Re: Choosing the proper disk setup. I need help and advice."
- Reply: Guadala Harry: "Re: Choosing the proper disk setup. I need help and advice."
- Reply: ComfortablySAD: "Re: Choosing the proper disk setup. I need help and advice."
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 26 Sep 2004 12:36:36 -0400
Here I come, a-top-postin'..
I agree with what Harry's written up below. I also think you may be
focusing too much on Disk I/O -- when it's likely not the cause of your
problem.
Sure, as Harry's written -- looking at indices is a good place to start.
Unfortunately, if you're locked into a "really" effing bad
application.. no amount of hardware will fix the problem. Be prepared
for that unfortunate reality.
In a previous life (about 2 years ago) I was supposed to make the
"network faster". The application was so badly broken that I could only
recommend throwing the appliation out (which would have been the best
choice) or tossing MASSIVE hardware at it to ensure that my VP didn't
get fired after the thing became a $3million (Canadian dollars) failure.
So, we went out and found -- TADA, the IBM x440. Yup, we loaded that
sucker up with like 8 CPUs (at 2GHz each) and 4 GB of ram and ..
something like 18 disk spindles across 4 SCSI channels.
It cost us about $120,000 (Canadian dollars, again) .. and you know
what it did?
It put the re-development of the app off for another 12-24 months.
At the end of the day:
- Ensure your hardware is redundant.
- Ensure you back your data up.. and know how to restore it.
- Don't fret too much about disk I/O most arrays go much faster than the
100 Mbps network cable you're plugging the machine into, regardless.
Chances are you're CPU bound, not Disk I/O bound.
>>2 x 18GB 15K ---> Operating System *.tmp files*
>>2 x 36GB 15K ---> *Main database file*
>>2 x 18GB 15K ---> *Main transaction log file*
>>2 x 18GB 15K ---> *Operating System Paging File*
First Pair:
OS .TMP files you think are a performance concern? I claim this is
inaccurate. The OS is going to do basically nothing -- once the machine
is up and running. Disk IO, CPU use and memory paging should be
absolutely minimal. Give 'em their own pair anyhow -- it's nice to be
able to rip the OS in and out at whim.
Second Pair:
For "Main Database File". This is going to be primarily read-oriented
disk IO transactions. If you can get the entire DB into a 36 GB pair --
great, go for it.
Third Pair:
The db Tranny log. This is primarily write-I/O transactions. If you
want to get really fun -- stick this on its own array controller with
loads of cache.
Fourth Pair:
for the OS page file? Nope. Never page anything. This is a misnomer
from the old days when RAM cost a lot. Best practice meets reality..
haha.
And.. finally, consider this: if your database is like sub-10GB in
total -- just buy enough RAM and stick the whole damned thing in RAM.
Nevermind the drives -- chips are a LOT faster. See? haha..
Good luck!
- Scott.
Guadala Harry wrote:
> A couple of thoughts.
>
> <<I have a SQL based application that has grown too taxing for the hardware
> it currently resides>>
> It appears that your solution is to increase I/O capacity... but have you
> established that inadequate disk I/O is in fact causing your performance
> problems? If not, then other likely culprits would be inadequate RAM,
> inadequeate CPU speed (or number of CPUs), or network I/O as the bottleneck.
> Oh, and a lack of good indexes in your database can contribute significantly
> to causing poor performance - and that is easy to fix (just good indexes) -
> oh, and poorly written queries or other data access logic...
>
> Assuming you have eliminated those other likely suspects and disk I/O is in
> fact the bottleneck, we need to answer your question -
> <<Will the performance increases be worth using this configuration?>>
> That's too difficult to answer with any reasonable feedback without knowing
> how bad things are right now (specifically in terms of I/O bottlenecks),
> your current disk configuration... We don't have enough info with which to
> compare your proposed disk configuration. And finally, *worth it* is highly
> subjective.
>
> Finally, suppose the proposed disk subsystem may in fact be the worst
> bottleneck in your system... but the next bottleneck is right on it's
> heels.... you get the idea.
>
> It might be helpful to run some performance counters and actually measure
> the extent to which of the likely suspects listed in my above blathering are
> at within acceptable limits. Then you'd have an objective measure against
> which you can know that any hardware changes actually improved things. You
> could do before/after measures and be able to communicate to others exactly
> how much better off you are (or aren't).
>
> Of the possible ways to improve system performance from a hardware
> perspective, going to a whole new disk subsystem is perhaps the most
> expensive and time-consuming, therefore (you fill in the blanks...).
>
> Good Luck.
>
>
>
>
> "ComfortablySAD" <ComfortablySAD@discussions.microsoft.com> wrote in message
> news:F0D6AAC5-4080-4BE3-8DAD-F13D2A1CED63@microsoft.com...
>
>>Hello,
>>
>>I have a SQL based application that has grown too taxing for the hardware
>
> it
>
>>currently resides. This application has recommended hardware setups, and
>
> best
>
>>practice documentation on how to achieve best performance. From these
>>documents I know how to best arrange the file system per "best practices".
>
> My
>
>>questions mainly have to do with hardware, but I'd also like to get
>
> feedback
>
>>on the actual performance increases of these recommendations.
>>
>>This application uses four main files to run. The best practices say to
>
> make
>
>>sure these four files on four separate physical disks to increase
>>performance. This makes sense seeing how the processors can then write to
>
> all
>
>>four simultaneously. Here is the setup I had in mind and the file
>
> suggested
>
>>to be on a separate disk is in *'s.
>>
>>Server- Dual Xeon 3.2Ghz 2MB Cache, 4GB RAM
>>(2 x because the disks will be mirrored.)
>>2 x 18GB 15K ---> Operating System *.tmp files*
>>2 x 36GB 15K ---> *Main database file*
>>2 x 18GB 15K ---> *Main transaction log file*
>>2 x 18GB 15K ---> *Operating System Paging File*
>>
>>Now this seems like a lot of disks to me, but it does follow all best
>>practices. It will also mean I'd have to set up four separate mirrors on
>
> the
>
>>controller card. Will the performance increases be worth using this
>>configuration? This is going to be Windows 2003 Server Standard edition
>
> and
>
>>the SQL app is Sybase version 9. The main DB file will be roughly 2GB if
>
> that
>
>>helps. And please suggest any configurations that may better suite my
>
> needs
>
>>or post links to lead me in the right direction.
>>
>>Thanks,
>>
>
>
>
-- ==================================================== Scott Davis, 45 Dunfield Av, Unit 2117 Self-Employed Toronto, ON, Canada, M4S 2H4 Tech Consultant Mobile. (416) 432-4334 The IP addrs I use to post all UseNet: 66.207.215.240/29 ====================================================
- Next message: Scott Davis: "Re: Forest Trusts are backwards?"
- Previous message: Timothy Drouillard: "Re: NT PDC can no longer administer users it it's own domain but can in others."
- In reply to: Guadala Harry: "Re: Choosing the proper disk setup. I need help and advice."
- Next in thread: Guadala Harry: "Re: Choosing the proper disk setup. I need help and advice."
- Reply: Guadala Harry: "Re: Choosing the proper disk setup. I need help and advice."
- Reply: ComfortablySAD: "Re: Choosing the proper disk setup. I need help and advice."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
