<div dir="ltr">Thread count is independent of number of servers. The number of sockets/connections is a function of number of servers/bricks. There are a minimum number of threads (like the timer threads, syncop exec threads, io-threads, epoll thread, depending on interconnect RDMA event reaping threads) and some of them (syncop and io-thread) count are dependent on the work load. All communication with servers is completely asynchronous and we do not spawn a new thread per server.<div>
<br></div><div>HTH</div><div>Avati</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 1:17 PM, James <span dir="ltr"><<a href="mailto:purpleidea@gmail.com" target="_blank">purpleidea@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Jan 30, 2014 at 4:15 PM, Paul Cuzner <<a href="mailto:pcuzner@redhat.com">pcuzner@redhat.com</a>> wrote:<br>
> Wouldn't the thread count relate to the number of bricks in the volume,<br>
> rather that peers in the cluster?<br>
<br>
<br>
</div>My naive understanding is:<br>
<br>
1) Yes, you should expect to see one connection to each brick.<br>
<br>
2) Some of the "scaling gluster to 1000" nodes work might address the<br>
issue, as to avoid 1000 * brick count/perserver connections.<br>
<br>
But yeah, Kelly: I think you're seeing the right number of threads.<br>
But this is outside of my expertise.<br>
<span class="HOEnZb"><font color="#888888"><br>
James<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br></div>