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

Avery Ching commented on GIRAPH-104:
------------------------------------

The reduction in the maximum amount of heap used for messaging during the life 
of an application is quite large.  As an example, here's some runs I did prior 
to the optimizations:

2011-12-12 22:57:51,961 INFO org.apache.giraph.graph.BspServiceWorker: 
startSuperstep: Superstep - after prepare 6 totalMem = 252.8125M, maxMem = 
252.8125M, freeMem = 122.46955M
2011-12-12 22:57:52,354 INFO org.apache.giraph.graph.BspServiceWorker: 
finishSuperstep: before flush - Superstep 6 totalMem = 252.8125M, maxMem = 
252.8125M, freeMem = 119.091606M
2011-12-12 22:57:52,354 INFO org.apache.giraph.comm.BasicRPCCommunications: 
flush: starting for superstep 6 totalMem = 252.8125M, maxMem = 252.8125M, 
freeMem = 119.091606M
2011-12-12 22:57:59,337 INFO org.apache.giraph.comm.BasicRPCCommunications: 
flush: ended for superstep 6 totalMem = 252.8125M, maxMem = 252.8125M, freeMem 
= 4.349098M
2011-12-12 22:57:59,337 INFO org.apache.giraph.graph.BspServiceWorker: 
finishSuperstep: Superstep 6 totalMem = 252.8125M, maxMem = 252.8125M, freeMem 
= 4.349098M
2011-12-12 22:58:01,403 INFO org.apache.giraph.comm.BasicRPCCommunications: 
prepareSuperstep: totalMem = 252.8125M, maxMem = 252.8125M, freeMem = 4.156639M
2011-12-12 22:58:04,426 INFO org.apache.giraph.comm.BasicRPCCommunications: 
prepareSuperstep: Superstep - after inMessage assignmnt 7 totalMem = 252.8125M, 
maxMem = 252.8125M, freeMem = 121.982346M

Note how the free memory would dip to 4 MB at times.  After the fixes I don't 
see the dips:

2011-12-12 23:39:49,260 INFO org.apache.giraph.graph.BspServiceWorker: 
finishSuperstep: Superstep 8 totalMem = 252.8125M, maxMem = 252.8125M, freeMem 
= 110.11537M
2011-12-12 23:39:49,274 INFO org.apache.giraph.comm.BasicRPCCommunications: 
prepareSuperstep: Superstep 9 totalMem = 252.8125M, maxMem = 252.8125M, freeMem 
= 110.102M
2011-12-12 23:39:49,458 INFO org.apache.giraph.comm.BasicRPCCommunications: 
flush: starting for superstep 9 totalMem = 252.8125M, maxMem = 252.8125M, 
freeMem = 103.08128M
2011-12-12 23:39:51,728 INFO org.apache.giraph.comm.BasicRPCCommunications: 
flush: ended for superstep 9 totalMem = 252.8125M, maxMem = 252.8125M, freeMem 
= 106.01724M
2011-12-12 23:39:51,728 INFO org.apache.giraph.graph.BspServiceWorker: 
finishSuperstep: Superstep 9 totalMem = 252.8125M, maxMem = 252.8125M, freeMem 
= 106.01724M
2011-12-12 23:39:51,747 INFO org.apache.giraph.comm.BasicRPCCommunications: 
prepareSuperstep: Superstep 10 totalMem = 252.8125M, maxMem = 252.8125M, 
freeMem = 105.48416M
2011-12-12 23:39:51,786 INFO org.apache.giraph.comm.BasicRPCCommunications: 
flush: starting for superstep 10 totalMem = 252.8125M, maxMem = 252.8125M, 
freeMem = 119.71583M
2011-12-12 23:39:51,786 INFO org.apache.giraph.comm.BasicRPCCommunications: 
flush: ended for superstep 10 totalMem = 252.8125M, maxMem = 252.8125M, freeMem 
= 119.5272M
2011-12-12 23:39:51,786 INFO org.apache.giraph.graph.BspServiceWorker: 
finishSuperstep: Superstep 10 totalMem = 252.8125M, maxMem = 252.8125M, freeMem 
= 119.5272M

We should include this ASAP.


                
> Save half of maximum memory used from messaging
> -----------------------------------------------
>
>                 Key: GIRAPH-104
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-104
>             Project: Giraph
>          Issue Type: Improvement
>            Reporter: Avery Ching
>            Assignee: Avery Ching
>            Priority: Critical
>         Attachments: GIRAPH-104.diff
>
>
> Currently, the amount of memory that Giraph uses for messaging is huge.  This 
> JIRA will reduce the messaging memory by half and provide periodic updates of 
> memory for debugging.  Details are below:
> Refactored RandomMessageBenchmark to an internal vertex class.  Added 
> aggregators to RandomMessagesBenchmark to track bytes, messages, and time for 
> the messaging.  Adjusted the postSuperstep() to be called after the flush() 
> for more accurate timings.
> Added periodic minute updates for message flushing (which can take a while, 
> especially on the memory benchmark).  This helps to see how progress is going 
> and gives an ETA.
> Memory optimizations include:
> - Clear the message list after computation 
> - Free vertex messages on the source as the flush is going on 
> - TreeMap -> HashMap for VertexMutations
> - Sizing the ArrayList properly in transientInMessages

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

        

Reply via email to