backtop


Print 27 comment(s) - last by EricMartello.. on Jul 29 at 5:38 PM


RamSan-440  (Source: Texas Memory)
Massive 4U SSD can sustain 600,000 IOPS

Solid state drives (SSDs) are being eyed as the future of enterprise data storage for the improvements in speed, reliability and energy savings they offer. SSDs for consumers are small devices very similar in size and shape to the traditional hard drive used in computer systems.

The SSD in an enterprise environment often takes on a different form factor though and the latest of these enterprise SSDs is from Texas Memory. Texas Memory says that its RamSan-440 can sustain a record setting 600,000 IOPS (input/outputs per second) and can be had with capacities of 256GB and 512GB.

The available storage space is a record for RAM-based SSDs. EWeek reports that the RamSan-440 is also the first SSD to use NAND flash modules in a RAID configuration for data backup. The SSD also uses proprietary technology from Texas Memory called IO2 (Instant-On Input-Output) that improves availability by making data requested from users or applications available instantly when the system is on.

The RamSan-440 uses DDR2 RAM reports eWeek and can sustain 4Gbps random read and write speed with a latency of under 15 ms. The device is in a 4U rack mount chassis and can be attached via SAN or directly attached via up to eight 4Gbps Fibre Channel ports.

Data backup is accomplished using RAID protected flash memory modules. Backup is done continuously to the internal flash modules with little impact on system performance. Pricing information is unknown, but considering that a ”cheap” consumer SSD with 128GB is right at $500, the RamSan-440 will cost a pretty penny.



Comments     Threshold


This article is over a month old, voting and posting comments is disabled

RE: Incomplete Info!?
By mkruer on 7/23/2008 2:38:32 PM , Rating: 2
I am not disagreeing with you, that this is an improvement.
The "ideal" cluster size currently is anywhere between 8k-64k depending on the data content not 1k using such a small block size will lead to additional performance overhead because the data is not saved in 1k blocks. The current ratio give them about 7.5K blocks at max IO and throughput, which is closer to the ideal 8k used my most databases.

Ideally you want a small index of clusters as possible and at the same time you want smallest block size as possible. unfortunately this is inversely proportional, and AFAIK this has never fundamentally changed.


RE: Incomplete Info!?
By poothedrew on 7/23/2008 5:19:43 PM , Rating: 2
Yes you are quite correct.

I was quite cavalier about the use of 1k. My comment was directed at transaction size rather than disk configuration.

Most benchmarking for transaction performance pick a 1 - 2 K data size for use with measureing disk systems.

Having said that sizing clusters to align with database page size is allways a good thing.


RE: Incomplete Info!?
By fibreoptik on 7/24/2008 10:36:48 AM , Rating: 2
hey everyone... he said "cavalier" :D


RE: Incomplete Info!?
By EricMartello on 7/29/2008 5:38:38 PM , Rating: 2
OR you could just set up the database properly: on a raw partition to eliminate file system overhead...then all you have to blame for bottlenecks is the hardware and the programmers of said database.

Benchmarks in general are "useless" if you're trying to determine real-world performance. Raw throughput varies with the type of request...to make an example more people would understand:

An apache web server can saturate a 100 Mbps connection by only serving static HTML pages/content. HOWEVER, if you are dealing with dynamic content like ASP or PHP and no caching, the server's ability to produce throughput drops substantially - in some cases by as much as 80%.


“Then they pop up and say ‘Hello, surprise! Give us your money or we will shut you down!' Screw them. Seriously, screw them. You can quote me on that.” -- Newegg Chief Legal Officer Lee Cheng referencing patent trolls

Related Articles













botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki