Slashdot Mirror
Intel Takes SATA Performance Crown With X25-E SSD
theraindog writes "We've already seen Intel's first X25-M solid-state drive blow the doors off the competition, and now there's a new X25-E Extreme model that's even faster. This latest drive reads at 250MB/s, writes at 170MB/s, and offers ten times the lifespan of its predecessor, all while retaining Intel's wicked-fast storage controller and crafty Native Command Queuing support. The Extreme isn't cheap, of course, but The Tech Report's in-depth review of the drive suggests that if you consider its cost in terms of performance, the X25-E actually represents good value for demanding multi-user environments."
This just screams dedicated database storage.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Try using a RAM disk.
Except those same drives don't exactly compare due to a poor implementation of the hardware or the write/cleaning algorithm in the JMicron controller many (all?) of those are using. The capacity and price are tempting, but the write latency especially during random accesses is beyond awful. Unless of course they were able to update the firmware on those chips to address the issue since this article was published: http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=7
It becomes a very fast cdrom - read only.
From the article: "The storage controller is an Intel design that's particularly crafty, supporting not only SMART monitoring, but also Native Command Queuing (NCQ). NCQ was originally designed to compensate for the rotational latency inherent to mechanical hard drives, but here it's being used in reverse, because Intel says its SSDs are so fast that they actually encounter latency in the host system. It takes a little time (time is of course relative when you're talking about an SSD whose access latency is measured in microseconds) between when a system completes a request and the next one is issued. NCQ is used to queue up to 32 requests to keep the X25-E busy during any downtime between requests."
"our Lotus Notes servers are almost as rough on the SAN as the DB servers, huge numbers of IOPS and almost as much storage."
I have no idea if you fall into this category, but many, MANY Domino administrators who implement with a SAN do so in a suboptimal fashion. A Domino server should have considerable resources on local drives even if you are committed to a SAN for your primary data storage. All system NSFs should be stored on local drives, as well as your transaction log (you are using transaction logs, right?) and a dedicated indexing swap drive.
If you're running Domino 8.0.1 or higher, you should use the non-summary item compression switch on your databases, as this can improve I/O demands by as much as 30%.
The newest version of Domino is due this quarter, and includes the new attachment and object storage model that can also dramatically improve I/O, since it's possible to move things like email attachments into an alternative storage location. (Whether this is on the SAN or not is up to you.)
As an IBM design partner, I've also been pushing the Domino server team to make some further improvements in I/O for future versions of Domino. Most significantly, this would include:
1) Permitting full-text indexes to be stored in a location other than a folder adjacent to the NSF. Right now, if you're storing mail files on your SAN, you *must* store FT indexes on the SAN as well. Which is rather limiting.
2) Pulling the view index collection object out of the NSF itself. When Domino builds a view index today, the $Collection object for that view gets stored similarly (not identically) to an attachment in the NSF itself. If you look at an NSF in the Administrator client, you can right click and select "Manage Views" to see the size impact this has on the database. More importantly, this results in dramatically more I/O to the NSF itself, and increases data fragmentation. So I've been beating the drum pretty hard to get IBM to pull that object content out of the NSF. (It was a choice many years ago to store it IN the file to keep administration simple in the days when Notes servers were brought up on NetBIOS LANs in broom closets.)
If you'd like to see these I/O improvement implemented, contact your IBM representative and beat that drum with me. :-)
And if you have any questions about any of this, feel free to contact me.