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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 PoliceAPK Mirror, Illogical Robot LLC
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-users

[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux