[Gluster-users] Gluster very poor performance when copying small files (1x (2+1) = 3, SSD)
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>
> 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
> # gluster volume set <volname> performance.write-behind-trickling-writes
> 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)
> Words are my own opinions and do not necessarily represent those of
> my employer or partners.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-users