SQL Server Performance Forum – Threads Archive
SCSI LUN addressing
Why has LUN addressing an impact on disk performance ?i believe you are referring to the practice creating logical unit out of arrays, then allocating the units to any application as necessary.
many SAN vendors believe their solutions are so powerful, that the underlying characteristics of the disk drive is no longer relevent (especialing with enough cache), hence they can do the above.
this is fundamentally not true for databases,
first, excessive cache on the SAN is a waste for databases. the database is already caching data in system memory, why double cache in the SAN as well, if you can afford more memory, put most of it in the server, the SAN only needs enough to buffer writes.
second, the database has two different disk usage patterns for data and logs,
the data is mostly random I/O, plus the checkpoint which cause very high queue depth.
the log should be almost entirely sequential writes, so even 2-4 dedicated physical disks (for each high volume log) should be able to handle even a high transaction volume database, with very low disk latency.
As so as the logs are mixed with data, directly or by use of LUNs, the disk latency go from <1ms to >20ms, meaning you now have a crippled system.
I have seen many cases where the standard SAN vendor "one-config-fits-all-users" approach resulted in absolutely horrible db performance, even though the storage solution was very expensive (>$500K)
I agree with Joe on this for high-end systems. Low end systems you can carve up many LUNS though and achieve higher performance many times on a SAN because you’re spreading IO across multiple drives and raising the overall utilization of many fast drives vs. a few slow drives that would normally be used. For our main OLTP system, we use two 6 disk RAID 5 arrays for data and two 4 disk RAID 10 arrays for logs. They’re all 72GB 15K drives. The other systems though are spread across multipe 5 disk RAID 5 arrays. We have 6 of those. They’re all 146GB 10K drives. The performance is just fine on these. You need to study your system and make design decisions accordingly. Also, make sure you don’t exceed the overall capacity of your cache or backplane. This is extremely important on a SAN. One busy system on a storage processor can bring every application on it to a grinding halt. MeanOldDBA
[email protected] When life gives you a lemon, fire the DBA.
]]>