On Tue, Mar 20, 2018 at 8:57 AM, Sam McLeod <mailingli...@smcleod.net> wrote:
> Hi Raghavendra, > > > On 20 Mar 2018, at 1:55 pm, Raghavendra Gowdappa <rgowd...@redhat.com> > wrote: > > Aggregating large number of small writes by write-behind into large writes > has been merged on master: > https://github.com/gluster/glusterfs/issues/364 > > Would like to know whether it helps for this usecase. Note that its not > part of any release yet. So you've to build and install from repo. > > > Sounds interesting, not too keen to build packages at the moment but I've > added myself as a watcher to that issue on Github and once it's in a 3.x > release I'll try it and let you know. > > Another suggestion is to run tests with turning off option > performance.write-behind-trickling-writes. > > # gluster volume set <volname> performance.write-behind-trickling-writes > off > > A word of caution though is if your files are too small, these suggestions > may not have much impact. > > > I'm looking for documentation on this option but all I could really find > is in the source for write-behind.c: > > if is enabled (which it is), do not hold back writes if there are no > outstanding requests. > Till recently this functionality though was available, couldn't be configured from cli. One could change this option by editing volume configuration file. However, now its configurable through cli: https://review.gluster.org/#/c/18719/ > > and a note on aggregate-size stating that > > *"aggregation won't happen if performance.write-behind-trickling-writes is > turned on"* > > > What are the potentially negative performance impacts of disabling this? > Even if aggregation option is turned off, write-behind has the capacity to aggregate till a size of 128KB. But, to completely make use of this in case of small write workloads write-behind has to wait for sometime so that there are enough number of write-requests to fill the capacity. With this option enabled, write-behind though aggregates existing requests, won't wait for future writes. This means descendant xlators of write-behind can see writes smaller than 128K. So, for a scenario where small number of large writes are preferred over large number of small sized writes, this can be a problem. > -- > Sam McLeod (protoporpoise on IRC) > https://smcleod.net > https://twitter.com/s_mcleod > > Words are my own opinions and do not necessarily represent those of > my employer or partners. > >
_______________________________________________ Gluster-users mailing list Gluster-users@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-users