September 19, 2007 at 11:17 am
I recently took a look at the configuration of one of our QA servers' RAID controller. The server is an HP ProLiant DL585 G1. The RAID controller was configured in a 50/50 config for caching, meaning half of the controller's cahce was for read, the other half was for write.
In our specific database application, write performance is more critical than read performance so I asked one of our system admins to look into changing the controller config to either a 25/75 read/write or a 0/100 read/write config. His statement to me is that the entire array would have to be reconfigured and reformatted to make this change.
I'm not quite clear on why this is. Is the SA feeding me a line or is this a true statement? Anyone else out there deal with this situation?
September 20, 2007 at 7:15 am
it depends on the model of the RAID controller. i changed this on a DL 380 G5 recently and no rebuilding required. it will warn you if it requires rebuilding so it shouldn't be any harm in trying. but i would run a full backup before anyway
September 22, 2007 at 12:06 am
SQL Noob,
We use DL380 G5's as well, our default build sets it to 50/50.. What did you change it to on your SQL Server? Did you notice any benefit?
September 24, 2007 at 4:15 am
I think you're being spun a line, I don't have experience of this array controller but i've changed cache and it didn't need an array rebuild - why would it, the two are not directly related.
btw. generally read cache degrades performance in my view - in the days when I could configure these things we proved that anything but write cache slowed down our oltp servers.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
September 24, 2007 at 7:51 am
It should be easy to find the answer about whether a rebuild is required in the documentation for the controller.
For heavy OLTP systems a 100 write/0 read configuration can show significant benefits for two reasons. Writes are usually what slow things down and most reads are not sequential.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
September 24, 2007 at 9:40 am
I'd be very interested to see any benchmarking you do with this. I'd agree that the write cache is more important on the controller. Read cache is held in memory on the server and unless you are hitting one table heavily (and it's small), not sure you get benefits.
SQL does do some read aheads in expectations of scans, which are sequential (depends on fragmentation), but unless lots of users are switching between two tables that can't be held in memory, not sure how the read cache on the disk controller would help.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
September 24, 2007 at 10:10 am
It might also depend on what array controller you have in the server. If you are using the 5i (battery backed, presumably or you wouldn't be able to change the accelerator ratio) then as far as I know you can set the read/write cache ratio on the fly using the ACU from inside the OS (http://www.icare.hp.com.cn/TechCenter_StaticArticle/8584/11183.pdf).
One whitepaper I have notes from suggests that the controllers have read cache built in, so setting the write to 100 % still gives you read cache memory (http://www.icare.hp.com.cn/TechCenter_StaticArticle/8584/11183.pdf).
Its probably worth asking the question in the HP ITRC forums for your specific controller (like this one http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=791212&admit=-682735245+1190649456424+28353475).
Read/write performance is also affected by stripe size. Stripe size would require array rebuilds, obviously. I would be surprised if read/write cache ratio changes on the fly would affect all but heavily loaded servers.
Update ---->
I just gave it a whirl on a P400i controller in a DL360 G5 using the ACU from inside Win Server 2003 R2 x64 SP2 (note this is a SAS controller, so its not going to be the same as the one you have installed). Changing the accelerator ratio while in the OS (with active VMs) was not a problem, no reboot or rebuild was required.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply