Are my SSD drives configured with RAID 0 defective?

I have two HP 1.2TB SSD drives connected to a Smart Array P420i. The performance is not good, slower than my SAS HDD. The two SSD drives were configured RAID 0, which gives me 2.4TB on a single Logical drive. I am not sure if the SSD drives are defective or something is not right with the P420i.

I have used several testing tools to compare the speed of these SSD drive on this RAID controller card, but the best test was to transfer a 88GB file between two partitions on the same logical drive, and the speed was 155MB/s.

Latest RAID controller firmware, version 8.32, is installed. Latest Windows driver version for this card is also installed.

Here are a few tests I ran, which seem to indicate a fast transfer rate, but in reality when I transfer a file from one partition to the other on the same SSD logical drive, I get 155-170MB/s.

Test with CrystalDiskMark on Partition D
Test with ATTO Disk Benchmark on Partion D with 512KB total length
Test with ATTO Disk Benchmark on Partion D with 2GB total length
diskspd_resultDetails.txt
ADUReport.txt
Slot0.txt
LVL 1
Robert LemMrAsked:
Who is Participating?
 
andyalderCommented:
SSDs sold for ProLiant servers should be OK on RAID controllers, they have enough free space to do GC in background without TRIM, if they were consumer drives however not using them on a RAID controller makes a lot of sense.

Might be worth turning Smart Path off, it's not exposed in the GUI as the drivers are meant to manage it but you can use the CLI vis:

hpssacli
controller slot=X array Y modify ssdsmartpath=disable
0
 
andyalderCommented:
Transferring huge files isn't what SSDs are designed for, they're designed for small block size high IOPS such as transactional databases.

Specs for 1.2TB SATA

Random Reads 60,000 IOP/s
Random Writes 10,200 IOP/s
Sequential Reads 470 MiB/s
Sequential Writes 310 MiB/s

You'll see that the sequential speed isn't that better than a spinning hard disk but the IOPS are far greater.

The performance is still lower than it should be though, do you have a cache module installed and are you using the latest drivers (otherwise SmartPath doesn't work). https://support.hpe.com/hpsc/doc/public/display?docId=mmr_kc-0125362&docLocale=en_US
1
 
noxchoGlobal Support CoordinatorCommented:
I would not use SSD drives in hard RAID configuration because the TRIM function would fail to work in this case. Instead a so called Software RAID using Windows tools in Disk Management is recommended.
0
Network Scalability - Handle Complex Environments

Monitor your entire network from a single platform. Free 30 Day Trial Now!

 
Robert LemMrAuthor Commented:
to andyalder <
Yes, I have a 2GB cache module and I recently install the latest firmware for the P420i. I also install the latest windows driver, and the latest Smart Storage Administrator.
I have disabled the Smart Path yesterday, but will try the CLI in case the GUI did not disabled it.

to Noxcho < Wouldn't the TRIM function only apply to Linux OS?
0
 
Robert LemMrAuthor Commented:
to andyalder < I am using this server for an SQL database of 100GB. That's all it is used for, but transaction logs can be large at times. My main concern is that if the write speed is between 400MB/s to 500MB/s, would transferring files be faster than 155MB/s, or I am missing some technical data?
0
 
andyalderCommented:
Transaction logs can grow to huge sizes but they only get written to in increments, I do think the main problem is with writing huge files.

What results do you get from SQLIOSim or IOmeter with a 64K random workload? Don't run them for so long that you wear out the SSDs ;)
1
 
pgm554Commented:
Firmware up to date?
Are you running write through or write back on the controller?
0
 
noxchoGlobal Support CoordinatorCommented:
Wouldn't the TRIM function only apply to Linux OS?
It applies to Windows as well. The short lifetime of early SSD drives was caused by missing TRIM.
0
 
Robert LemMrAuthor Commented:
to pgm554 < Only write through exists on the Smart Array P420i. That's per HP's manual on the controller.

to noxho < Ah! I need to learn more about Windows TRIM. I am more of a Linux guy. Per what I read, in relation to the current enterprise level SSD drive,s TRIM is not really needed.  However, I ran "fsutil behavior query DisableDeleteNotify" and got a "0," which indicates that Windows is set to TRIM automatically. I have been running some tests and will post them in a minute. Thanks for your suggestion.
0
 
Robert LemMrAuthor Commented:
to pgm554 < Yes, firmware is up to date. I installed version 8.32 on the P420i a couple of days ago, the day after I installed the SSD drives.
0
 
Robert LemMrAuthor Commented:
to andyalder < I have added a few tests on my original question, for you to look at. Thanks for you time.
0
 
pgm554Commented:
Write through is generally slower on systems that do write-intensive applications.

Write back is faster on systems that do write-intensive applications.

I'm wondering why HP would take away that option.
Is this battery backed cache?
0
 
andyalderCommented:
The performance spikes just where you need it for sql, but the result column is in mb/s rather than iops so hard to interpret
0
 
Robert LemMrAuthor Commented:
to pgm554 < yes this RAID card is battery backed cache (2GB). I can check with HP why Write Back is not available on this RAID card.

to andyalder < thanks, I have added the result details from diskspd which measure in iops.
0
 
andyalderCommented:
Write back cache is disabled on SSD arrays if smart path is enabled because when it bypasses the RAID stack and lets the driver read directly from the SSD the data has to be there and not just on the cache DIMM. Otherwise write back is enabled by default although HPE call it write cache.

If you upload an ADUreport from HPSSA we can check the cache status.
0
 
Robert LemMrAuthor Commented:
to andyalder < Interesting! I have attached the ADUreport and the Slot0 report. Thank you.
0
 
Robert LemMrAuthor Commented:
to andyalder < Were you able to look at the ADUreport and the Slot0 report?
0
 
andyalderCommented:
Seems OK but I would change the cache read/write ratio to 10% / 90% so it can do a bit of read-ahead.
0
 
Robert LemMrAuthor Commented:
Ok, and thank you. I will do this change
0
 
Robert LemMrAuthor Commented:
andyalder < you earlier said "Transaction logs can grow to huge sizes but they only get written to in increments, I do think the main problem is with writing huge files."

Per all the tests I have done, It is true that the SSD is much slower when writing big files such as 63Gb. Is there something I can do to improve this, or that's as much as I am going to get. Could the way the drives were formatted (stripesize,  queue depth) be a factor?

Thanks for your help.
0
 
andyalderCommented:
I don't think there is much you can do, you are getting 310 MBps (since you are reading and writing the same device we have to double your 155MBps). SQL writes can be up to 256Kb so that would be a good strip size. You can't really control the queue depth except in the benchmarking software.
0
 
Robert LemMrAuthor Commented:
I have done several tweaks based on all answers. I have been able to get 430MB/s manual transfers of very large files--much faster on smaller size files. My SQL database, the transaction logs and the tempDB have no waits anymore. Meaning that the I/O is optimum for the current amount of transactions per second. Thank you all.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.