You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@giraph.apache.org by "Eli Reisman (JIRA)" <ji...@apache.org> on 2012/11/04 22:46:11 UTC

[jira] [Commented] (GIRAPH-389) Multithreading should intelligently allocate the thread pools

    [ https://issues.apache.org/jira/browse/GIRAPH-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490299#comment-13490299 ] 

Eli Reisman commented on GIRAPH-389:
------------------------------------

That makes sense, I was not able to use the "instantiate our own ZK" option last summer, I was always using the cluster quorum. I wonder if the single-instance scales well enough to make it the default, a lot of the stuff I was troubleshooting around ZK back then had a lot to do with slowdowns during frequent writes & quorum sync's that you guys never have to worry about. After all, we don't have to have a ZK that is 24-7 available, just per-job. May I ask whats the most worker tasks you've run on a single ZK this way?


                
> Multithreading should intelligently allocate the thread pools
> -------------------------------------------------------------
>
>                 Key: GIRAPH-389
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-389
>             Project: Giraph
>          Issue Type: Bug
>            Reporter: Avery Ching
>            Assignee: Avery Ching
>             Fix For: 0.2.0
>
>         Attachments: GIRAPH-389.patch
>
>
> Even if the user suggests a very high number of threads, the input split threads should not exceed the number splits divided by the number of  workers.
> The number of compute threads should not be greater than the number of partitions on that worker.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira