On Tue, Mar 20, 2018 at 8:57 AM, Sam McLeod <mailinglists@xxxxxxxxxxx> wrote:
Hi Raghavendra,On 20 Mar 2018, at 1:55 pm, Raghavendra Gowdappa <rgowdapp@xxxxxxxxxx> wrote:Aggregating large number of small writes by write-behind into large writes has been merged on master: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:
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@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-users
