[Gluster-users] To good to be truth speed improvements?
dijuremo at gmail.com
Fri Jan 18 13:35:12 UTC 2019
The OP (me) has a two node setup. I am not sure how many nodes in Artem's
configuration (he is running 4.0.2).
It can make sense that the more bricks you have, the higher the performance
hit in certain conditions, given that supposedly one of the issues of
gluster with many small files is that gluster has to stat the files in all
the bricks (I would assume where they reside), so this is what creates the
high latencies which lead to bad performance with many small files.
I am no expert on the internals of how it works, so I am not 100% sure
On Fri, Jan 18, 2019 at 8:22 AM Andreas Davour <ante at update.uu.se> wrote:
> On Thu, 17 Jan 2019, Artem Russakovskii wrote:
> > When we first started with glusterfs and version 3 last year, we also
> had a
> > ton of performance issues, especially with small files. I've made several
> > reports at the time, hopefully some of them helped.
> > However, at some point, possibly after updating to v4 (currently using
> > 4.0.2), the performance issues went away. Poof. I imagine when we upgrade
> > further, performance may improve even more.
> > When we were running v3, I was desperately considering
> > alternatives/competitors. Not anymore, gluster has performed perfectly
> > without a single durability issue for almost a year now.
> If I understood correctly you only have two bricks, is that correct? I'm
> working at a site with gazillions of bricks and the performance is
> terrible, and I suspect there's a sweetspot where you don't want too
> many bricks compared to nodes. It would be interesting to investigate
> that further.
> "economics is a pseudoscience; the astrology of our time"
> Kim Stanley Robinson
> Gluster-users mailing list
> Gluster-users at gluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-users