Properly redistributing the data partitions shared by 20 workers if the
next superstep will run on only 15 workers (for example) would be
prohibitive performance wise for most use cases I think?
In the "Pure YARN" Giraph profile this functionality and many similar
things will be fairly easy to im
Does anyone have any thoughts on how to have Giraph not require a fixed
amount of workers, but rather be able to start a superstep with a possibly
smaller number of workers?
On Thu, Oct 10, 2013 at 4:12 PM, Manuel Lagang wrote:
> I'm trying to understand the meaning of the 3 parameters to
> Gira
I'm trying to understand the meaning of the 3 parameters to
GiraphConfiguration.setWorkerConfiguration: minWorkers, maxWorkers, and
minPercentResponded. I want my Giraph jobs to co-exist nicely with other
jobs in the cluster, and it's not always the case that I can get a fixed
number of map slots f
