August 4, 2005 at 4:50 pm
A solid state hard drive from Texas Storage is a little out of our budget. Has anyone tested / tried the Gigabyte i-RAM with SQL Server? All the reviews I can find online are aimed at workstations or gamers. I suspect the solid state nature of the thing will make the thing perform better than a disk when SQL Server slams a couple of hundred IO requests at the database files. Our test environment server uses SATA drives anyway so it's not like the interface is a step down for us (compared to someone with SCSI disks). Performance is miserable when multiple queries are run as is and we strongly suspect the disks. We could fit our test DB in a pair of iRams RAIDed together.
Thanks in advance for any helpful comments.
August 5, 2005 at 8:24 am
Why not do some benchmarking first to see if the disks really are the problem. Go to performance monitor and watch the Physical Disk: Avg. Disk Queue Length If these are really high, look at seperating you log files from you data files - put them on seperate disks. Then run your tests again.
The i-RAM looks cool, but with only a 12 hour backup battery and static being able to wipe your data away, I would be somewhat leary.
You could also look at http://www.quickshift.com/index.shtml
They have a free trial, see if it works.
If you do the iRAM thing, let me know how it works and for your own safety do lots of backups.
August 5, 2005 at 8:56 am
It would be interesting to have some testing done. 12 hour is interesting, what about putting tempdb on it? Lots of order bys, group bys, etc, might benefit from it.
August 5, 2005 at 11:27 am
"Why not do some benchmarking first to see if the disks really are the problem"
Yes, well, the disk queue length is regularly in the hundreds, which is why I suspected the disks as the bottleneck. The point of my question is about the iRam card for general curiosity, not getting help determining my particular situation. Since they're only manufacturing 1,000 of the things I don't think I'll be able to get my hands on one anyway.
12 hours without power is a lifetime to a proper datacenter; that isn't really a concern. Anyway, you'd restore it off a traditional disk and do regular backups to the same just in case. The issues related to the battery life go away with a little forethought and planning.
August 5, 2005 at 5:04 pm
Texas Memory Systems did performance test on there solid state storage device, but it is not cheap device. You can go to http://www.superssd.com/products/ramsan-400/ and download the pdf on sql server. Its shows a vast improve for certain scenarios. Also, there bandwidth is not limited by the SATA 150 interface. I believe it probably will help for the scenarios decussed in the pdf, but you have to make sure it is a IO related issue.
August 6, 2005 at 11:25 am
Here's what it boils down to:
Texas Memory: $30,000 for 8GB = $3,750 per GB
iRam: $150 + $1,944 for 8GB = $261 per GB.
3,750 / 261 = 14
Therefore:
The iRam only has to be better than 1/14th the performance of a TMS to be cost effective.
August 8, 2005 at 2:03 pm
A number of years ago (over 7-8) I did a solid state disk benchmark for an internet stock trading company using SCSI-II disks and solid state disks on Compaq hardware using SQL v7.0. The trading system was mature and could handle 1 million stock trades (37 sql insert/update/select per stock trade) in less than 4 hours. We tried configurations of database file groups on solid state, data only on solid state, index only on solid state and data/index on solid state. We ran millions of transactions through the databases for each scenario and just found negligable performance increases. We even switched from SCSI-II arrays to EMC SAN and achieved the same results. Of all the permutations that we tried the biggest performance improvement came when we used the solid-state disk for transaction logs only (we met the vendors 300% increase in i/o speed claim !). So the if you really want things to scream, 98% of your space should be SAN, 2% should be solid state disk. But only is you need millions of transactions a day !
If you do not need that high a transaction volumen then I'd bone up on perfmon and profiler to identify the real performance issues before trying to spend any more money.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply