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 

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: 
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to