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 though.
Diego
On Fri, Jan 18, 2019 at 8:22 AM Andreas Davour <ante@xxxxxxxxxxxx> 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 and
> 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.
/andreas
--
"economics is a pseudoscience; the astrology of our time"
Kim Stanley Robinson
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-users
