giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Reisman (JIRA)" <>
Subject [jira] [Commented] (GIRAPH-249) Move part of the graph out-of-core when memory is low
Date Mon, 16 Jul 2012 17:38:35 GMT


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:
>             Project: Giraph
>          Issue Type: Improvement
>            Reporter: Alessandro Presta
>            Assignee: Alessandro Presta
>         Attachments: 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:!default.jspa
For more information on JIRA, see:


View raw message