Showing posts with label dedicated. Show all posts
Showing posts with label dedicated. Show all posts

Friday, March 23, 2012

Optimize RAID configuration

I am setting up a server that will be a dedicated database server. I don't have much flexibility in choosing a server, and the servers we use are limited to six disk drives. There will be only one user database on the server, aside from the system databases. Everything I have read indicates it is better to place the transaction log file on a separate disk array from the data files. I could put the transaction log file on a mirrored disk array (RAID 1) and then put the data file on a RAID 10 array of four disks. But where would I put the OS and SQL binaries? The application in question is fairly write-intensive, and does not perform well in a RAID 5 array. In the past, we placed everything (OS, data, logs, etc.) on the same RAID 5 array. It is apparent that this configuration is not going to work, or at least it won't scale very well. My questions are as follows:

1) How much write activity is generated by the transaction log? Will I see a tangible performance benefit by separating the log file onto its own physical array?

2) What would be the optimal RAID configuration for the above scenario, while limited to six drives?

3) What would be the optimal RAID configuration if I had more that one user database on the same server, with the six drive limit?

Any help would be very much appreciated.As a GENERAL rule, you want to seperate your log files, databases and indexs from each other. In your case I doubt if you will have much oppertunity to optimize your hardware.

IMnsHO, I would put the os, binaries and logs on the RAID 1 drives and db et all on the RAID 10 drives. I suspect you have a single channel controler so watch disk I/O as I would bet you will have a bottleneck here. If you have a dual channel controler put the RAID 1 on one channel and the RAID 10 on the other.

Your question...

1) Every write to a table will generate a write to the transaction log even in Simple mode! Putting your logs on a RAID one drive will increase performance on a write intensive db.

2) It is more a question of RAID configuration and controler configuration. Unless you have a dual channel controler you aren't going to see much of a performance increase. Switching from RAID 5 to RAID 1 & 10 will help. Make sure the data cache on the controler is optimized for more writes than reads.

3) Get a three channel controler, channel one for the RAID 1 drives, channel two and three for the RAID 10 drives, mirror across the two channels so the strip stays on one channel.

Optimizations for machine dedicated to processing

Hello,

We have a machine entirely dedicated to processing SSAS 2005 cubes, and then other machines sync from it and provide client access.

I notice that sometimes during processing, the processor usage hovers at about 15% and there is no paging or disk activity, which makes me wonder if SSAS is somehow limiting resources used for processing. Are there any optimizations that can be made to tell SSAS to assume that it doesn't have to serve clients, and can devote all resources to processing? I'm looking specifically at the Thread Pool / Process / Priority Ratio, which it says is an advanced property not to be changed without guidance--could increasing this work?

Thanks for any ideas.

Tom

You should be able to use several tools to monitor what is happening during processing of Analysis Services cubes:

SQL Profiler- will show you trace events
ActivityViewer sample app- will show you current connections, sessions..

Try to see what stage of processing is going slow on your machine. In several cases I have seen Analysis Server sitting and waiting for data to come from relational database.

Processing of partition has several stages:
Read Data , Write Data , Build Index ...

See which part is under suspicion.

I wouldnt go changing advanced sever properties without talking to product support.

Hope that helps.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.