Databases Reference
In-Depth Information
and the SAN. This is why the SAN that's connected over NFS can't even serve as many
random reads per second as you'd expect from a single locally attached hard drive.
We've benchmarked with larger file sizes, but we didn't have results at those sizes for
all of the above systems. The outcome, however, is always predictable: no matter how
large and powerful the SAN, you can't get good response times or throughput for small,
random operations. There's just too much latency due to the distance between the
server and the SAN.
Our benchmarks show throughput in operations per second, and they don't tell the
full story. There are at least three other important metrics: throughput in bytes per
second, concurrency, and response time. In general, compared to directly attached
storage, a SAN will provide good sequential throughput in bytes per second for both
reads and writes. Most SANs can support lots of concurrency, and we benchmarked
only a single thread to illustrate the worst case. But when the working set doesn't fit
well into the SAN's caches, random reads will be very poor in terms of throughput and
latency, and even when it does, latency will be higher than with directly attached
storage.
Using a SAN over NFS or SMB
Some SANs, such as NetApp filers, are commonly accessed over NFS instead of via
Fibre Channel or iSCSI. This used to be something you'd want to avoid, but NFS works
a lot better these days than it used to. You can get decent performance over NFS,
although the network needs to be configured specifically for it. The SAN vendors pro-
vide best practice guides that should help you with configuration.
The main consideration is how the NFS protocol itself affects performance. Many file
metadata operations, which are typically performed in memory on a local filesystem or
a non-NFS SAN, can require a network round trip with NFS. For example, we've no-
ticed a severe performance penalty from storing binary logs on NFS, even with
sync_bin
log
disabled. This is because appending to the binary log increases its size, which re-
quires a metadata operation that causes an extra round trip.
You can also access a SAN or NAS over the SMB protocol, and similar considerations
apply: there can be a lot more latency-sensitive network round trips. These don't matter
much for the typical desktop user who's storing some spreadsheets or other documents
on a drive he's mounted, or even for operations such as copying backups to another
server, but it can be a serious mismatch for the way MySQL reads and writes its files.
MySQL Performance on a SAN
The I/O benchmarks are one way to look at things, but what about MySQL perfor-
mance on a SAN? In many cases, MySQL works just fine, and you can avoid many of
the situations where the SAN would cause some degradation in performance. Careful
logical and physical design, including indexing, and appropriate server hardware (lots
