Re: threads translator best practice

[Raghavendra G <raghavendra@xxxxxxxxxxxxx>]

Hi Thomas, 

please find the inlined comments.

On Wed, Apr 1, 2009 at 11:29 PM, Thomas Conway-Poulsen <tconway@xxxxxxxxxxxx> 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@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel

-- 
Raghavendra G