[Gluster-devel] threads translator best practice

Raghavendra G raghavendra at zresearch.com
Tue Apr 7 07:56:11 UTC 2009


Hi Thomas,

please find the inlined comments.

On Wed, Apr 1, 2009 at 11:29 PM, Thomas Conway-Poulsen <tconway at adpepper.com
> wrote:

> Hi guys,
>
> I have been pondering about the threads translator and where to put it, at
> the top just below the physical disk or at the buttom as the exporter..
>
> On the server, what happens if all other translators like iocache, locks
> and writebehind are threaded - do I have to calculate the memory consumption
> times the count of threads, and if so - what about object uniqueness,  if
> one thread is cached but the other dont know about it ?


Memory consumption remains same irrespective of the number of threads.
caching is not done on per thread basis.


>
>
> Maybe, there is no need to to use the threads translator just above
> protocol level. If the server only has one CPU, but it would still make
> sense to use it before the physical disk so that scsi queueing could be used
> properly to get the most IOPS out of them..
>
> Any idea in using the threads at both protocol and disk level maybe ?


for 2.0 releases, io-threads is not needed at protocol in a single cpu
system. But io-threads would still be needed on top of posix/posix-locks
since operations to/from physical disk might be blocking.


>
> From what I have understood, on the server-side - put the iothreads just
> after locks. On the client side, just before the protocol...


io-threads is not needed  on top of protocol/client.


>
>
> A lot of questions, maybe you can just supply me with a best practice when
> using the non-blocking translator ?
>
> Best regards,
>
> Thomas.
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20090407/be456ec1/attachment-0003.html>


More information about the Gluster-devel mailing list