[
https://issues.apache.org/jira/browse/GIRAPH-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13415433#comment-13415433
]
Eli Reisman commented on GIRAPH-249:
------------------------------------
Second run on same data with smaller splitmb made it to completion! I was able
to complete the same job as trunk would do, in the same time, but on less
workers without blowing up. Very nice! I will run some more data through it
now. I do think given how you have set this up it would make a nice buffer in
emergency situations where certain workers are riding close to the edge. This
is critical because one dead worker == whole dead job. It will be really
important to test this against algorithms that mutate the graph in-progress
since that is where every partition will need to be loaded in memory for every
super step with no exceptions, and this could make disk IO a speed and memory
drain rather than a help. But perhaps it could be set with a -D option so that
vertex authors could choose to engage it or not depending on the algorithm they
are running. For non-mutating graphs I think it is definitely a helpful
addition to the code.
I will run some more data through it and see how it does. I do think the fact
that splitmb sizes more in keeping with HDFS block sizes should be possible but
are not. Tweaking this to cache all incoming collections of vertices during
INPUT_SUPERSTEP and then read them back into memory when all splits are read
and super step 0 is about to begin would be a huge win I think, allowing fast
data reads and optimizing on block-size HDFS sequential reads speeds.
Anyway, I'll run more tests, really great work!
> Move part of the graph out-of-core when memory is low
> -----------------------------------------------------
>
> Key: GIRAPH-249
> URL: https://issues.apache.org/jira/browse/GIRAPH-249
> Project: Giraph
> Issue Type: Improvement
> Reporter: Alessandro Presta
> Assignee: Alessandro Presta
> Attachments: GIRAPH-249.patch, GIRAPH-249.patch, GIRAPH-249.patch,
> GIRAPH-249.patch, GIRAPH-249.patch
>
>
> There has been some talk about Giraph's scaling limitations due to keeping
> the whole graph and messages in RAM.
> We need to investigate methods to fall back to disk when running out of
> memory, while gracefully degrading performance.
> This issue is for graph storage. Messages should probably be a separate
> issue, although the interplay between the two is crucial.
> We should also discuss what are our primary goals here: completing a job
> (albeit slowly) instead of failing when the graph is too big, while still
> encouraging memory optimizations and high-memory clusters; or restructuring
> Giraph to be as efficient as possible in disk mode, making it almost a
> standard way of operating.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
