Hi all!
First of all, please excuse the typo I made in my posting.
I had written
>> There may be some merit to this in a specialized setup (NAS systems -
>> I'm not convinced of them, but don't claim expert knowledge about them),
and of course meant SAN, not NAS systems.
As regards NFS:
Peter Chacko wrote:
> And NFS is becoming better and better with the adoption of 10GbE, and
> NFSoRDMA ...i am sure at that point no body will complain about NFS
> performance for databases. And for a parallel database access, pNFS is
> also shaping up well. As NFS creators are now owned by ORACLE who
> themselves have developed technology like direct NFS, NFS and Database
> storage will be great buddies in future.
>
> thanks
>
> On Fri, Aug 7, 2009 at 11:37 PM, Gavin Towey<gto...@ffn.com> wrote:
>> I always accepted that NFS was unacceptably slow for database access,
>> until I actually tested it. Turns out that with lots of RAM and properly
>> tuned caches, you're optimizing for minimal IO anyway. A good file server
>> will have massive amounts of IO OPS. On top of that if you're using GigE
>> over few hops, then it's really not slower than local disks.
I immediately agree that NFS becomes faster due to technical progress,
like any other part of computing.
But however clever you optimize your NFS setup (including the network,
the servers, ...), you always have the additional latency of the network
and the NFS server (compared to the local disk).
Remember: Database performance is not only about throughput, it is also
about latency.
So NFS can only be slower than a local disk, never the same turnaround
time, let alone faster (assuming equal disks and machines, of course).
Whether that is *too* slow is another question - depending on your
software, your workload, and your hardware it may be fast enough.
However, my main objection against using NFS for database storage is not
performance, it is complexity:
If your database server does not use local disks but NFS, then the
network between the database server and the NFS server as well as that
server suddenly become essential components for your database setup.
As any component may fail, you increase the risk to your DB.
You may reduce the individual risk by selecting better hardware, dual
controllers, dual cabling, mirrored machines, ... as much as you like,
the result will still be higher complexity and higher risks than if you
had applied similar enhancements to your database server and its local
disks.
>>
>> Remember: benchmark and test your assumptions!
Agreed.
Regards,
Jörg
--
Joerg Bruehe, MySQL Build Team, joerg.bru...@sun.com
(+49 30) 417 01 487
Sun Microsystems GmbH, Komturstraße 18a, D-12099 Berlin
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
