I'd be really interested in how this stacks up using V2.4-dev-11 (or later) with FSAL_VFS. That build includes my work to support multiple file descriptors, which ALSO includes streamlining the OPEN operation. Note that currently FSAL_VFS is the only FSAL to benefit from that streamlining, but anyone working a different FSAL would be encouraged to implement the extended FSAL API (support_ex and methods like open2). Note that I have yet to implement create2 which might help if your create load includes non-regular files.
The extended API holds the most opportunity in this area for FSALs other than FSAL_VFS that have the possibility of implementing open2 completely down into the underlying filesystem (the open2 method exposes the FSAL to all the semantics of the NFS v4 OPEN operation). We have plans for subsequent performance attention to work at handling multiple operations from a single COMPOUND into a single FSAL call. One specific area of improvement would be explicit GETATTR handling as requested by the COMPOUND performed in the same call to the underlying filesystem as the associated operation (OPEN, READ, WRITE, etc). This would also benefit NFS v3 (by being able to manage the post op attributes the same way). Thanks Frank > -----Original Message----- > From: Tushar Shinde [mailto:[email protected]] > Sent: Wednesday, April 13, 2016 3:21 AM > To: Tushar Shinde <[email protected]>; J. Bruce Fields > <[email protected]>; [email protected] > Subject: Re: [Nfs-ganesha-devel] NFSv4 open close operations are slow > compared to Linux kernel NFSv4 > > I did test with Kernel nfs and Ganesha, With sync and NFS_Commit = True; > 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. > 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 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ 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
