QuicksearchDisclaimerThe individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
|
SSD at SunTuesday, September 16. 2008Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
What I find interesting is that most of the current SSD slutions for netbooks are not much faster than the usually used notebook winchester disks (i.e. slower than Server Disks).
It is not like SSD is always much faster than the HD we know. This might be suprising, but you need to consider that before opting for SSD. Battery backed (NV)RAM might be much much faster.
We donīt talk here about consumer electronics. Your considerations are based on consumer class SSD. But iīve heard this several times in the past since some PC hardware outlets benchmarked consumer-class SSD.
Enterprise SSD for server systems and Notebook SSD (especially for el-cheapo netbooks) doesnīt use the same technology (for example SLC in enterprise vs. MLC in consumer, different controller chips, size of DRAM caching area). Of course battery backed NVRAM is faster, but itīs also vastly more expensive. It isnīt out of reach to create a 1 TB SSD storage for the L2ARC (just 4 256GB SSD), whereas a 1TB DRAM based storage is extremly expensive. At a given cost budget a SSD based variant give you more power, as you get more L2ARC based on FLASH-SSD than you would get by using DRAM-SSD. Thus on a given budget a DRAM-SSD would send you much earlier to the rotating rust obliterating the performance advantage of DRAM-SSD ...
I wonder how SSD works for incoming mail message queues where lots of small random and synchronous writes happen.
Let's say 100 messages per seconds mostly within the size of a couple of kilobytes Is SSD already up to this task? If yes, my guess is our infrastructure will look a lot different in a couple of years. There is an interesting article at http://storagemojo.com/2008/09/09/our-changing-file-workloads/ about the read/write ratio of data today. I guess for mail systems the read/write ratio will be even higher for writes (e.g. Spam will only be written once, and mostly never read again, and Spam is the reason #1 for peaks beside X-mas Thinking again about it, the storage backend should be able to constantly receive an average number of messages, but the ZIL must be able to handle peaks. What's your opinion?
There are write-biased and read-biased SDDs on the market. We will announce products for this task soon.
My opinion: SSD are already up to this task. At 3000 IOPS write with 4k blocks even for a plain-vanilla enterprise SSD drive, you have a huge advantage against a high RPM rotating rust drive specīd at 320 IOPS max.I assume, you can vastly reduce your SPAM spindles, especially when you donīt cheat and keep the best practice to queue the mail without synchronous write semantics. Yes, your infrastructure will look a lot different from your actual one. But it will not only influence your storage. Your server configuration will look different, too. Today you use as much memory as possible to get your database completly to the memory, as with 320 IOPS per disks even large buches of disks will kill your performance. An SSD will give you a relatively cheap way to build out a L2ARC cache that helps you to reduce the impact when the database has to go to the disks. SSD may influence the infrastructure in a way, that we use less big main memory in the servers in favour of a big L2ARC on enterprise SSD.
dann kann es ja nicht mehr lange dauern, bis man diese geheimnisvollen Teile auch kaufen kann...
Yeap ... dauert nicht mehr lange, bis die auf der Sun Preisliste stehen ...
Hi Joerg,
On slide 6 the highest IOPS rating is 156. On page 10 it states 320 IOPS is attainable with 15K RPM drives. Which one is giving the correct picture ?
Both are correct. 320 is the marketing number. Iīve "stealed" some of slides from official marketing slides. But this assumption is on shaky feets. 156 is the worst case(full turn)/technical answer to the IOPS question.
PS: This is the problem of the missing voice track .... i explain this difference in my presentation, but i didnīt thought about that while puting the presention online. |
+1The LKSF bookThe book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0Contact
Networking xing.com My photos Buttons![]() This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Germany License
![]() ![]() ![]() Blog AdministrationDonateOkay, okay ... as several people have asked for it ... but you know my opinion.
|