Hi Supriti, On Thu, Dec 14, 2017 at 4:26 PM, Supriti Singh <supriti.si...@suse.com> wrote: > Hello all, > > At SUSE, we did a performance benchmarking for nfs-ganesha v2.5.2 for FSAL > Ceph and RGW. For FSAL CEPH, we did a comparison for kernel cephfs client > and nfs-ganesha. Please find report attached. > > Key points > 1. Earlier, I shared results on ceph-devel mailing list as well. I have > added comparison between those results and current results on page 9. In > earlier test, I did not tune the parameters "Dispatch_Max_Reqs" and cephfs > default pool size. That could be one reason, why ganesha performs better in > the current test. Thanks to Malahal for pointing out the parameters. > > 2. For multiple clients and multiple jobs, single nfs-ganesha server > performance degrades significantly. As we go ahead, active-active > nfs-ganesha server or pnfs may improve performance. Any thoughts on this? I > did stumble upon Jeff's blog: > https://jtlayton.wordpress.com/2017/11/07/active-active-nfs-over-cephfs/ Is > this something already in loop for 2.7?
I have reason to believe that the request queuing and throttling behavior in versions before 2.6 is responsible for a lot of the degradation, even with good tuning. I'm very interested to see your results with 2.6. Looking forwards, yes, I think pNFS hsa the potential to help out a lot. Also, I believe there are available speedups in libcephfs, but I haven't worked with it in a long time. > > 3. For NFS-RGW, as it supports only sync write, I was not able to use fio > for testing. Is there any other tool that someone else has used? The semantics of FSAL_RGW were designed as those of upload, not full NFS semantics, so the usual benchmarks dont really work. Im not sure what to suggest, beyond less general benchmarking, like copying up some large files. I'm working on removing the restricted upload semantics in Mimic. > > 4. For 2.6, I am aware that "Dispatch_Max_Reqs" goes away. But I have not > looked into code, so please excuse if question is not to the point. Are > those changes expected to improve performance? Yes. Fairness between clients should be improved. You may want to experiment with different (larger) values of nb_worker in 2.6. post 2.6 we're moving to async dispatch. > > 5. Also, I think it would be nice to have event messages for tunable > parameters. So that if nfs-ganesha is slowing down, because some parameters > have reached threshold values, users can understand for the log messages. I > am only aware of health messages, but it does not explain what could be > wrong. > > Please let me know your feedback, if I missed out on some optimization or > analysis. > > Thanks, > Supriti > > ------ > Supriti Singh > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, > HRB 21284 (AG Nürnberg) > > Matt -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
