Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Why would a heavily disk intensive application run faster on a SAN than on a Physical Disk? I would have expected the Physical disk to be slightly faster but in fact the process ran 100 times faster when it's work drive was set to a partition on the SAN.

Our guess is that the SAN is optimised out of the box to be fast whereas the physical disk tuning settings are OS (Solaris) related and have not been touched or the OS patched.

During the highest activity the disk I/O was running at 100% and the time to complete a write was over 2 seconds as several processes were writing to the disk at the same time.

(FYI the application involved was Informatica PowerCenter)

share|improve this question
add comment

4 Answers

up vote 23 down vote accepted

I'm not at all surprised. SAN arrays typically have a LOT of disks involved. The limiting factor for disk I/O is the speed of the individual disk, and these stack. 6 drives locally in a RAID10 will perform better than 2, and 80 drives on a SAN will perform better than 10 drives locally. There are variables of course, but that's how it's supposed to work.

Also, if the SAN has any SSDs involved, things get really zippy.

share|improve this answer
add comment

It's almost certainly due to caching. The DAS probable has minimal caching, where most Enterprise SANs have multiple gigabytes of cache. I'd guess the app is saturating the DAS's cache, but not the SAN's.

share|improve this answer
1  
Obvious latency on the SAN is going longer than the DAS but overall throughput is higher on the SAN with all it's caching. Good answer. –  Matt Sep 9 '11 at 0:18
    
and then there is often a read ahead cache so its random read/writes that take the biggest hit and then you can cache writes so its only random reads that get impacted, still a pretty small delay though. –  Silverfire Sep 9 '11 at 0:52
1  
A properly configured Storage Subsystem on the SAN that isn't overloaded should be giving you random write times around 1-2ms. –  MikeyB Sep 9 '11 at 4:09
    
@MikeyB I'm not disagreeing with you. 1-2ms write to SAN seems right. But Charles' SAN config was 100 times faster than his overloaded physical disks (writes were > 2sec for latter). So even his SAN performance isn't so good, at 20ms rather than 1-2ms...? –  Feral Oink Sep 9 '11 at 8:26
add comment

Conceptually it always feels like serving disk from SAN should be slower than serving it locally. However, there are plenty of factors which can reverse this and result in the SAN being a much faster option. Some of these factors are:

  • Does your workload require fast seek time or fast throughput, or both?
  • How many spindles on the SAN LUN versus the local disk?
  • What bus speed between the SAN LUN and the server, versus the local disk interface?
  • How much read/write cache is available on the SAN LUN vs the local disk?
  • What speed are the disks spinning at on the SAN LUN versus the local disk?
  • What other IO activity is taking place on the SAN LUN versus the local disk?
  • What RAID level are the arrays on the SAN and local storage?

All of these will affect your performance on SAN and local disk.

share|improve this answer
add comment

It all comes down to how many spindles are available.... The higher number of spindles the quicker it is to access any given piece of data. if you are heavy IO intensive, particularly if you are a database app, then you can quite easily bury local disk performance with a SAN solution which can have a far higher number of disk sets for the management of core data, indexes and such.

With the local disk subsystem you are also likely sharing access to the read/write heads with other operations, such as r/w to swap, local OS and library file access, application access, etc... While individually fast, the collective time for all of the read/write actions to move the read/write heads from one area of the disk to cover one set of actions to another to satisfy your application requirements can certainly beat on performance.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.