[Gluster-users] performance.cache-size for high-RAM clients/servers, other tweaks for performance, and improvements to Gluster docs

[Artem Russakovskii]

Hi,

I'm trying to squeeze performance out of gluster on 4 80GB RAM 20-CPU
machines where Gluster runs on attached block storage (Linode) in (4
replicate bricks), and so far everything I tried results in sub-optimal
performance.

There are many files - mostly images, several million - and many operations
take minutes, copying multiple files (even if they're small) suddenly
freezes up for seconds at a time, then continues, iostat frequently shows
large r_await and w_awaits with 100% utilization for the attached block
device, etc.

But anyway, there are many guides out there for small-file performance
improvements, but more explanation is needed, and I think more tweaks
should be possible.

My question today is about performance.cache-size. Is this a size of cache
in RAM? If so, how do I view the current cache size to see if it gets full
and I should increase its size? Is it advisable to bump it up if I have
many tens of gigs of RAM free?



More generally, in the last 2 months since I first started working with
gluster and set a production system live, I've been feeling frustrated
because Gluster has a lot of poorly-documented and confusing options. I
really wish documentation could be improved with examples and better
explanations.

Specifically, it'd be absolutely amazing if the docs offered a strategy for
setting each value and ways of determining more optimal values. For
example, for performance.cache-size, if it said something like "run command
abc to see your current cache size, and if it's hurting, up it, but be
aware that it's limited by RAM," it'd be already a huge improvement to the
docs. And so on with other options.



The gluster team is quite helpful on this mailing list, but in a reactive
rather than proactive way. Perhaps it's tunnel vision once you've worked on
a project for so long where less technical explanations and even proper
documentation of options takes a back seat, but I encourage you to be more
proactive about helping us understand and optimize Gluster.

Thank you.

Sincerely,
Artem

--
Founder, Android Police <http://www.androidpolice.com>, APK Mirror
<http://www.apkmirror.com/>, Illogical Robot LLC
beerpla.net | +ArtemRussakovskii
<https://plus.google.com/+ArtemRussakovskii> | @ArtemR
<http://twitter.com/ArtemR>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20180405/37dfaa25/attachment.html>