June 26, 2008 at 4:13 pm
I was at Microsoft TechED and in one the sessions, the guy mentioned that SQL full throttle can be achieved by setting SAN write cache/ buffer to 100% and 0% for the read. The thinking was that SQL is a read ahead design and does not need SAN controllers to do its work. He believes having read caches raises more inefficienies than it resolves. At a customer lab, they set this configuration and SQL2K5 was crawling. So they moved the read cache up to 288 and backed down the write to 1198. I do not know why these numbers were picked. My guess is some forum but they saw instantenous performance boosts.
anybody have any best practice thoughts around this read and write cache settings on the disk controllers?
June 26, 2008 at 4:29 pm
Sounds like you took one of Joe Changs classes.... 🙂
The rationalization wrt SAN Cache is that the SQL Server already has a cache (RAM) and is trying to utilize it as much as possible. Here comes your SAN vendor, putting another cache in front of your already cached app (SQL Server). So now the SAN is trying to optimize IO for the already-cached SQL Server, and a SAN sometimes fails at that pre-pre-caching and can cause issues.
You'll also only see a max IO throughput as a % of how much SAN cache you have...
Ie: 2GB SAN cache will allow you ~200MB/s across the HBA as all the IO _has_ to pass through the SAN cache on the way in/out. By removing the SAN cache, all IO is 'direct'. At least thats the theory.
Myself, I've never had a test SAN that I could test that theory on. Also, I've never had an isolated SAN to myself, where I can change the cache for my dbservers needs. But who knows what it would do to the Exchange guys performance...
Your friendly High-Tech Janitor... 🙂
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply