On Wed, Apr 13, 2016 at 03:50:43PM +0530, Tushar Shinde wrote: > I did test with Kernel nfs and Ganesha, With sync and NFS_Commit = > True;
You want "sync" for knfsd and "NFS_Commit = False" for Ganesha for an apples-to-apples comparison. (Which, happily, is also the default in each case.) That said, > Following are results, > > KNFSv4 > --------------------------------------------------------- > Operation total_ops-nsec ops/s > --------------------------------------------------------- > create 110000- 668159357063 164.631378 > open 110000- 266032790536 413.482880 > close 220000- 872624163550 252.113129 > > Ganesha V4 > --------------------------------------------------------- > Operation total_ops-nsec ops/s > --------------------------------------------------------- > create 110000- 694286669184 158.435989 > open 110000- 408155570824 269.505066 > close 220000- 1028802481561 213.840851 > > The time measured is in nsec by using clock_gettime(CLOCK_REALTIME) like, > start_timer(); > open() or operation > stop_timer(); > > The open operation is very slow (About 30-34%), I am finding it > consistently slow across multiple runs. Please note there is no IO > done no-read and no-write, Just open and close. If there are no writes then the results may turn out to be the same. So I think it's likely there's some Ganesha problem here, but it might still be worth rerunning with NFS_Commit off, just to make sure. --b. > In this open I had not used O_CREAT its only O_RDWR. > I observed cih_fh_cmpf is most frequenty called function, So I tried > to increase cache_sz and nparts but that did not resulted in > significant change. > > cache_inode/cache_inode_hash.c > 75 uint32_t cache_sz = 32767; /* XXX */ > 85 npart = cache_param.nparts; > > I will debug this again, But till then, If you know any tunables which > can affect this code path please let me know. > > > Thank you, > Tushar. > > > > > On Tue, Apr 12, 2016 at 11:08 PM, Malahal Naineni <[email protected]> wrote: > > Tushar Shinde [[email protected]] wrote: > >> I had used async with kernel and NFS_Commit = FALSE; with Ganesha. > >> Do you think still it will be unfair comparison? > > > > Usually NFS clients are smart and they send write with FILE_SYNC if > > they don't have any more writes. There are some clients (VMware I think) > > that do "write followed by commit" even if they have just one write. > > To avoid this follow on commit, ganesha syncs the data and tells the > > client about it with "NFS_Commit = True". > > > > Usually, we don't recommend "NFS_Commit = True" unless you have such a > > client. Ganesha always honors commits and there is no way to mimic > > kernel NFS's async option. > > > > As others have commented, use "sync" and compare. > > > > Regards, Malahal. > > ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Nfs-ganesha-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
