Mtron SSD benchmark

Before we start

One of the problems i am struggling with for many years now are I/O's on disks. As an ISP we host millions of small files like images, html documents and e-mails.

In total we host around 400 million files which are requested at random by our customers and the visitors of their websites.

This has always been a problem for our company. A regular S-ATA disk does around 100 I/O's per second, the fast FibreChannel or SAS disks do around 180 ~ 200 I/O's This are best situation numbers, but our servers do a lot of random requests, so the disk heads keep making full strokes to gather all the data requested.

So we kept adding and adding more disks to increase the number of I/O's. But this didn't statisfy me at all, we kept adding more disks, we were able to store more data (in theory) but when we stored more data, we needed more disks because the number of I/O's increased.

I kept following the development of SSD's closely but none of them really were what i was looking for. Random reads were always great, but the sustained reads were pretty slow and writes were even worse.

A few weeks ago i was browsing the web again and i ran into a test of the Mtron MSP 7025-032 at Tomshardware.com, i was stunned!

Single Mtron SSD

I only had one SSD available, so i wasn't able to test the RAID performance.
The test system:

• Ubuntu Linux (2.6.22 kernel)
• Intel Core2Duo 6420
• 2GB DDR2
• Intel Corporation 82801H S-ATA controller (Asus motherboard)

I first started with the the sustained read and write performance. I also had a server (specifications below) available to which i will compare the results.

The test server:

• Ubuntu Linux (2.6.15 kernel)
• Dual Opteron 270
• 4GB DDR ECC
• Areca ARC-1220 RAID-5 Controller
• 8x WD Raptor 74GB 10k RPM

hdparm
With hdparm you can measure the sustained reading speed of a disk.

seeker.c
seeker.c is a little C program with which u can benchmark the random read performance of a disk. It is available from http://www.linuxinsight.com/files/seeker.c

Reading and Writing a 10GB file
With “dd” i wrote a 10GB to the disk and then read it back into a blackhole (/dev/null)

Write: dd if=/dev/zero of=10GB.bin bs=1024k count=10240
Read: dd if=10GB.bin of=/dev/null

In these three tests you see the big difference between the Mtron SSD and the old fashioned harddisks. The access-time to the data is almost zero on the SSD where the harddisk has the bottleneck of its mechanical components.

Sustained reads and writes are lost by the SSD, but this is against 8 harddisks. When you devide the results by 8 a single SSD wins from the harddisks.

These were the first tests i ran when the SSD was in my desktop. I was sold, i contacted SSDisk.eu and ordered 4 Mtron 32GB SSD's for further benchmarking.

4x Mtron SSD in RAID-5

A few days later i was back in Antwerp for another 4 Mtron SSD's. This time i bought them instead of borrowing one.

In the datacenter i made the following setup:

• SuperMicro 2U case with 8 Hot-Swap S-ATA bays (with redundant power supplys)
• Intel Core2Duo CPU
• 1GB DDR2 Memory
• Areca ARC-1220 RAID Controller
• 2x 80GB S-ATA in RAID-1 (for the Operating System)
• 4x 32GB Mtron in RAID-5 (32KB blocksize)
• Ubuntu Linux (2.6.22 kernel)
• Enterprise iSCSI Target

The RAID controller disk information

The RAID controller volume set information

We work a lot with iSCSI. We export our blockdevices throug iSCSI to our servers, like MySQL database-servers.

The biggest challange was to solve the performance issue's we had on our database-servers. Regular harddisks were not able to access the data fast enough. Because of this, the requests stacked up, since all the servers were waiting on their data.

I configured the machine with LVM (Linux Volume Management) and exported one iSCSI LUN of 10GB to a database-server.

hdparm
At first i tested hdparm on the local RAID-5 array, not over iSCSI.

seeker.c
I also tested the seek performance of the RAID-5 array with seeker.c

Reading and Writing a 10GB file
With “dd” i wrote a 10GB to the disk and then read it back into a blackhole (/dev/null)
Write: dd if=/dev/zero of=10GB.bin bs=1024k count=10240
Read: dd if=10GB.bin of=/dev/null

As you can see, the results are great, but they were not as i expected.

The ~280MB/sec read and ~150MB/sec write performance were a bit disappointing, i expected more of it.

After some research about the Areca RAID-controller i found out that the CPU on the RAID-controller is the bottleneck, in RAID-5 mode it simply doesn't go any faster.

It was time to setup the iSCSI Target and connect one of the database-servers to the Mtron SSD's.

iSCSI Export
On top of the RAID-5 array i used LVM (Linux Volume Management) to devide the ~70GB into smaller devices of 10GB each (6 in total).

The smaller devices i exported with Enterprise iSCSI Target to my database-servers.

But before this setup could go into production, i had to test the “real life performance”.

I setup the following MySQL database-servers for some test:

• SuperMicro Blade-Enclosure
• 2x Intel Quad Core Xeon
• 8GB DDR2 Memory
• 2x Gbit NIC (Intel)
• Ubuntu Linux (2.6.22 kernel)
• ReiserFS filesystem
• MySQL 5.0.45

With Open-iSCSI i logged on to the iSCSI target and created a ReiserFS filesystem on the target.

I configured MySQL to use that iSCSI target as its datadir and i was ready to do some benchmarks.

MySQL benchmark

For benchmarking the MySQL performance i loaded a SQL-dump (made with “mysqldump”) into the MySQL database.

I used our customer database, this database contains 7.5 million records and has a total size of 3.5GB.

Not very much in size when measuring in GB's, but a pretty large database when counting in the number of records.

I also tested this when using the same WD Raptor disks (In RAID-5) as storage backend.

I measured the time it took to load the database-backup into the MySQL-server.

After loading the backup, i tested how much time it took to dump the database again to a SQL-dump (with “mysqldump > /dev/null”)

The results show how big the difference is. Although the Mtron SSD's are not that fast in random writes, i think the cache on the Areca controller helped a lot here.

But still, the SSD's were a lot faster then the WD Raptor disks. When dumping the data you see the great difference between the SSD's and the harddisks. Since dumping the data only involves reads, the Mtron's can show their real muscles!

Postmark
This is a tool developed by NetApp (one of the largest storage vendors), with this tool you can benchmark your filesystem/storage by performing random writes, reads with a lot of transactions in the queue.

In my situation i used a configuration with lots of small files, this since we are focused on serving small files like e-mails, images, html-documents, etc, etc.

I used the following configuration:
set read 4096
set write 4096
set transactions 10000
set size 500 500000
set number 5000

I measured the time in seconds it took the Mtron SSD's and again the WD Raptors to finish the benchmark:

As you can see, the SSD's were a lot faster, again! Since the benchmark contained a lot of random read operations, the SSD's were able to perform this a lot faster, because of their low access-times.

Real life performance
These were all the tests i performed, after these tests i was convinced.

At the moment one of our database-servers is running on these Mtron SSD's in RAID-5 and the performance is amazing.

The load (Linux) dropped from 5.00 ~ 6.00 to an amazing 0.50 ~ 1.50!
I can make backups whenever i want, even at “rush hour” (19:00 – 22:00) without any performance impact.

My customers are also very happy with this, they also noticed the great performance increase.

Conclusion

A single Mtron SSD is great for reading, but when writing, the performance is almost the same as a regular harddisk.

But when put into a RAID configuration on a true hardware RAID-controller like an Areca, the performance is amazing.

Especially the low access-times are great. When serving small files or randomly searching for data, the Mtron SSD's are really the cutting edge of what is available at the moment.

The price of the Mtron's may be a bit high for a home user, but for corporate use in a web, mail or databaseserver they are really worth it.

Author: Wido den Hollander