giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Reisman (JIRA)" <>
Subject [jira] [Commented] (GIRAPH-389) Multithreading should intelligently allocate the thread pools
Date Sun, 04 Nov 2012 21:46:11 GMT


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:
>             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:

View raw message