[Gluster-users] Gluster very poor performance when copying small files (1x (2+1) = 3, SSD)

Raghavendra Gowdappa rgowdapp at redhat.com
Tue Mar 20 03:56:38 UTC 2018

On Tue, Mar 20, 2018 at 8:57 AM, Sam McLeod <mailinglists at smcleod.net>

> Hi Raghavendra,
> On 20 Mar 2018, at 1:55 pm, Raghavendra Gowdappa <rgowdapp at 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:


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20180320/1ccd96ef/attachment.html>

More information about the Gluster-users mailing list