incubator-giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Avery Ching (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GIRAPH-12) Investigate communication improvements
Date Wed, 28 Sep 2011 07:22:45 GMT

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

Avery Ching commented on GIRAPH-12:
-----------------------------------

I wonder if Runtime methods measure the stack sizes of the threads consuming all that memory?
 My guess is no.  Since we're using less threads, we should have less stacks consuming all
the minimum memory.  I agree that the heap memory won't change much in going to your approach.
 I'm not sure how to prove that thread stack memory is being reduced if Runtime fails to capture
this though.  

One crude way would simply be to increase the heap space with your test until you find a maximum
heap size that can be used in your code and the original code.  If your code can reach a higher
heap allocation, than that should prove a memory win (more memory can be used for the heap).
 Here's some arguments to try out that approach if you're interested:

-Dmapred.child.java.opts="-Xms2750m -Xmx2750m"

As you bump up the -Xms and -Xmx values simultaneously, eventually your job won't start and
hopefully your changes enable a higher limit...
                
> Investigate communication improvements
> --------------------------------------
>
>                 Key: GIRAPH-12
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-12
>             Project: Giraph
>          Issue Type: Improvement
>          Components: bsp
>            Reporter: Avery Ching
>            Assignee: Hyunsik Choi
>            Priority: Minor
>         Attachments: GIRAPH-12_1.patch, GIRAPH-12_2.patch
>
>
> Currently every worker will start up a thread to communicate with every other workers.
 Hadoop RPC is used for communication.  For instance if there are 400 workers, each worker
will create 400 threads.  This ends up using a lot of memory, even with the option  
> -Dmapred.child.java.opts="-Xss64k".  
> It would be good to investigate using frameworks like Netty or custom roll our own to
improve this situation.  By moving away from Hadoop RPC, we would also make compatibility
of different Hadoop versions easier.

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

        

Mime
View raw message