<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 19, 2019 at 12:48 PM <<a href="mailto:lemonnierk@ulrar.net">lemonnierk@ulrar.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Apr 19, 2019 at 06:47:49AM +0530, Krutika Dhananjay wrote:<br>
> Looks good mostly.<br>
> You can also turn on performance.stat-prefetch, and also set<br>
<br>
Ah the corruption bug has been fixed, I missed that. Great !<br>
<br>
> client.event-threads and server.event-threads to 4.<br>
<br>
I didn't realize that would also apply to libgfapi ?<br>
Good to know, thanks.<br>
<br>
> And if your bricks are on ssds, then you could also enable<br>
> performance.client-io-threads.<br>
<br>
I'm surprised by that, the doc says "This feature is not recommended for<br>
distributed, replicated or distributed-replicated volumes."<br>
Since this volume is just a replica 3, shouldn't this stay off ?<br>
The disks are all nvme, which I assume would count as ssd.<br></blockquote><div><br></div><div>They're not recommended if you're using slower disks (HDDs for instance)</div><div>as it can increase the number of fsyncs triggered by replicate module and their slowness</div><div>can degrade performance. With nvme/ssds this should not be a problem and the net result</div><div>of enabling client-io-threads there should be an improvement in perf.<br></div><div><br></div><div>-Krutika</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> And if your bricks and hypervisors are on same set of machines<br>
> (hyperconverged),<br>
> then you can turn off cluster.choose-local and see if it helps read<br>
> performance.<br>
<br>
Thanks, we'll give those a try !<br>
</blockquote></div></div>