<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 31, 2019 at 10:01 AM Xavi Hernandez &lt;<a href="mailto:xhernandez@redhat.com">xhernandez@redhat.com</a>&gt; 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"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>I&#39;ve been doing some tests with the global thread pool [1], and I&#39;ve observed one important thing:</div><div><br></div><div>Since this new thread pool has very low contention (apparently), it exposes other problems when the number of threads grows. What I&#39;ve seen is that some workloads use all available threads on bricks to do I/O, causing avgload to grow rapidly and saturating the machine (or it seems so), which really makes everything slower. Reducing the maximum number of threads improves performance actually. Other workloads, though, do little I/O (probably most is locking or smallfile operations). In this case limiting the number of threads to a small value causes a performance reduction. To increase performance we need more threads.</div><div><br></div><div>So this is making me thing that maybe we should implement some sort of I/O queue with a maximum I/O depth for each brick (or disk if bricks share same disk). This way we can limit the amount of requests physically accessing the underlying FS concurrently, without actually limiting the number of threads that can be doing other things on each brick. I think this could improve performance.</div></div></div></blockquote><div><br></div><div>Perhaps we could throttle both aspects - number of I/O requests per disk and the number of threads too?  That way we will have the ability to behave well when there is bursty I/O to the same disk and when there are multiple concurrent requests to different disks. Do you have a reason to not limit the number of threads?</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"><div dir="ltr"><div dir="ltr"><div><br></div><div>Maybe this approach could also be useful in client side, but I think it&#39;s not so critical there.</div></div></div></blockquote><div><br></div><div>Agree, rate limiting on the server side would be more appropriate.</div><div><br></div><div><br></div><div>Thanks,</div><div>Vijay </div><br></div></div>