Optimal Stripe Size?

Hello readesgs

Enabling HDD caching will improve performance. The cache on the HDD is not battery backed, so in the event of a power loss the data may be corrupted. If you have the server connected to a UPS then sudden power loss should not be an issue.

The stripe size will have very little impact on performance. It can definitely improve performance, but typically will not have a huge impact. The biggest impact on stripe size is better drive space utilization. If the stripe size is set properly it can greatly increase drive space efficiency. Changing the stripe size will require deleting and recreating the array if you decide to change it.

I am not very familiar with Xen, but you might increase performance by moving the host OS to different drives than what the VMs are using.

Thanks

Daniel, little correction....

Actually what we are setting by choosing the stripe size is the stripe segment size, the stripe size has NO impact on the drive space utilization what so ever, unlike changing a hard disk sector size, which can have a big impact on space utilization. A stripe segment is how much of a file is written to all the disks in an array before a new segment is written to, but there is no law that data from another file can not be written in a stipe segment  immediately following the end of a previous file if the previously written file does not utiize a full stripe segment  (unlike certain hard disk sector use).

Also I have changed the "stripe size" on raid 1 and raid 10 for tweaking the stripe size for databases many times in the past, without destroying data, with no isssues... with parity raids this is not possible. Changing the stripe size can have a big impact on performance but  mainly for a server providing data of a specific data chuck size such as a SQL server or Exchange server. For a general use server , with varied programs and data types, changing the default stripe size is almost always a bad idea. Changing the stripe size is always a trade off, a specific sized data chuck will speed up, but  many other sizes will slow down., so unless you have a dedicated server to a very specific data size, it is not advisable.

mysqldba.blogspot.com/.../raid-stripe-size-raid-stripe-segment.html

Readesgs, Microsoft has tunning guides for each of the OS versions....., just search google for     Microsoft Performance Tuning Guidelines (fill in the OS)

such as.....

http://msdn.microsoft.com/en-us/library/windows/hardware/gg463392.aspx

also are these SAS or SATA,?  7.2k sounds slow for SAS, also a big for SAS

Thanks for the info and correction. I'll double check with our RAID guru tomorrow on this info.

Thanks to both for your replies. I had a look at the XenServer dmesg logs last night and saw this:

[    4.846416] sd 0:2:0:0: [sda] 7811891200 512-byte logical blocks: (3.99 TB/3.63 TiB)

Does this suggest XenServer is writing 512K blocks and if so would increasing the segment size in the PERC utility to 512K have any benefits whatsoever?

There are so many variables affecting performance in a raid it  is impossible  tell without benchmarking  each stripe size setting, and running the programs you have on the server with data (subject testing). Many times it is not the raid causing performance issue. Issues with SMB signing, SMB versions, network errors, driver issue  ect all can make an array appear slow.

As to benchmarks, you really need to run a few different benchmark programs, and then you need to use the server programs to get a subjective benchmark as to how it affects all areas such as queries, data input, data reads etc. Basically it a pain to benchmark properly.

I would try hard drive cache as Daniel suggested if you have a BBU, some times it has little or negative affect other times it can increase performance considerably, definitely worth a shot.  Also make sure you defrag your arrays frequently, a normal array will maintain a 4-5% increase in performance if defraged often. A  defrag program which does boot time defrags can increase DB  speeds 12-15% over an array which has never had a boot defrag. Boot defrags require a reboot and to this day they still scare me, though I have never had an issue; once or twice a month is plenty.  

Definitely read the tunning guides.... if you make changes, document everything so you are able to reverse the changes.