One of our support engineer gurus, Harsha, has published a very detailed post on tuning parameters for the Linux kernel that may impact your GlusterFS performance. Here’s his introduction:
Every now and then, questions come up here internally and with many enthusiasts on what Gluster has to say about kernel tuning, if anything.
The rarity of kernel tuning is on account of the Linux kernel doing a pretty good job on most workloads. But there is a flip side to this design. The Linux kernel historically has eagerly eaten up a lot of RAM, provided there is some, or driven towards caching as the primary way to improve performance.
For most cases, this is fine, but as the amount of workload increases over time and clustered load is thrown upon the servers, this turns out to be troublesome, leading to catastrophic failures of jobs etc.
Having had a fair bit of experience looking at large memory systems with heavily loaded regressions, be it CAD, EDA or similar tools, we’ve sometimes encountered stability problems with Gluster. We had to carefully analyse the memory footprint and amount of disk wait times over days. This gave us a rather remarkable story of disk trashing, huge iowaits, kernel oops, disk hangs etc.
This article is the result of my many experiences with tuning options which were performed on many sites. The tuning not only helped with overall responsiveness, but it dramatically stabilized the cluster overall.
When it comes to memory tuning the journey starts with the ‘VM’ subsystem which has a bizarre number of options, which can cause a lot of confusion.
It’s a great article. Read the whole post.