[email protected] said: > This could be a contributing factor, and may be worth testing, but I will > mention that each of these R720's is connected a zpool comprised of a couple > hundred SAS spindles each, and each R720 has ~192GB of memory. > > So even if we don't have an external log device per se, I feel fairly good > about the RAM-based ZIL doing a pretty good job of handling synchronous > writes efficiently. > > In addition -- wasn't sure how effective an external log device is at > absorbing huge streams of sequential writes? Seems like it would just get > filled up and you'd eventually be constrained by your spindles anyway.
Hi Ray, When "zfs set sync" is "default" or "always", the cache flushes triggered by synchronous writes go all the way out to non-volatile media, so server RAM (ARC) is not very relevant. For NFS, it's not the bandwidth or IOPS of your ZIL devices that kills performance. The latency of your server hardware is small compared to the latency involved in the network round-trip of the synchronous write traffic between NFS client and NFS server. In my experience, even the amount of cache in an H800 (512MB or 1024MB) will make a huge difference to the "tar x" workload from an NFS client (unless you're extracting small numbers of big files, in which case there is little synchronous traffic). The early generations of NetApp's made due with only a couple hundred MBytes of NVRAM, so it really doesn't take much. Granted, my experience has been with gigabit ethernet, so 10GbE latency could be good enough to alleviate the synchronous-write penalty. However, disabling synchronous writes on the NFS server is a quick way to see if this is what's going on. And if it is, a utility like "zilstat" will tell you how much external log you might need. Regards, Marion _______________________________________________ nfs-discuss mailing list [email protected]
