• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1183
  • Last Modified:

disk performance issues


IBM 3650 M3
RAID 10 using m5015 with BBU (Write Cache Enabled)
-all drives are used in the RAID 10 Array
16 x 146gb 10k rpm sas drives
stripe size 1mb
12gb ram
dual qc xeon

Function:  VMWARE esxi 4.x Server, running 3-4 vm.  

There will be an oracle db server, and app server, and windows server 2003

Problem:  Disk Performance. Currently when copying a 3gb USR folder on the same disk & vm it takes over 3 minutes to copy.

I was thinking part of the problem is the disk stripe size i chose in the RAID setup?  Is there a recommendation of a stripe size for this config above?  The server is not in production yet, waiting to solve the disk performance issue.

  • 2
1 Solution
VMWare segments I/Os to 64KB in each VM.  So you want to make sure that each VM is configured for 64KB NTFS I/O size.  Anything else is less efficient.  Also, in general your I/O is going to be random as far as VMWare is concerned.  

You would be better off redoing the storage, and taking 2x146GB drives, and making a RAID1 out of it, and then nailing it to a specific machine so it has direct access to it.  Then put your most I/O intensive stuff there.  Yes, it somewhat defeats the purpose of VMWare, but if you make it the D or E drive instead of the C drive, then you will still have easy migrations and such.

Also if your partitions were never set up as aligned on 64KB, then you need to do that.  
There is always much discussion about these sorts of issues.
Optimising your disk performance is often a complex process.
As mentioned raid 1 mirror is generally going to yeild the best read/write performance but this is only the case when talking overhead partity which you will experience with any raid 5 or 6 configuration.
There is also the issue of a single spindles I/O limits. Depending on the type of SAS disks you have purchased (single or duel chanel, 3Gb or 6Gb) will dictate the actual spindle limitations and of course how many SAS chanels are driveing the disks.
I'd hazard a guess that your raid10 would be fine.
A strip of 64K is optimum but asny multiple of 64K should be also be acceptible although 1MB is rather large.
More importantly you also need to align the starting sector and format to a cluster size which is matched to your application/average file write size.
For alignment try vOptimiser.
For format review the  Oracle write size. it will be divisable size of 64K I suspect. SQL has a standard of 4K.
I recently optimised a standalone server which was suffering periodic i/O issues. The average I/O load reduced by about 25%.
We at work have over the past few months spent approx 100 hours realigning guest sessions. Do it right from the start.
A tip, of you use the standalone importer is missalignes the disks..
freycomAuthor Commented:
They are 6gb and i was mistaken, I had 128 kb stripe, and the write cache was disabled.  I enabled write cache.

Performance is better.  Do have recommendation on how to test Disk speed in Red hat ES?

Should i still drop the cache size?
Start sector (or offset) is now your most important issue to address.
anything that's a multiple of 4K is ok but 64K is the standard most work to.

When you say the cache size do you mean the memory cache on the controller?
If so I'd say test a 50% split but more than likely a 75% dedicated to write and 25% to read would be my suggestion.
Also you mentioned it was taking 3 minutes to write a 3GB file.
Considering your writing to local disk not a SAN that's not too bad. The best I'd expect you to get would be 1.5 to 2GB per minute..if writing random files. If streaming large files you should get better..
Remember it's still only local disk in a server not a SAN.
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.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now