giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hyunsik Choi (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (GIRAPH-12) Investigate communication improvements
Date Sat, 01 Oct 2011 08:49:45 GMT

     [ https://issues.apache.org/jira/browse/GIRAPH-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Hyunsik Choi updated GIRAPH-12:
-------------------------------

    Attachment: GIRAPH-12_3.patch

Avery,

Thank you for your comments. Yes, I agreed that the aggregated wasted memory should be considered
=)

In the latest comment, I investigated the real occupation of thread stack by using Sleep class
(https://gist.github.com/1249761). When I created 2000 Sleep threads with the default stack
size option '-Xss4096k', the memory usage of both the process and all threads is only 46 mega
bytes.

So, I would like to say that the individual thread consumes much less stack size than default
thread stack size. The default thread stack size affects the virtual memory area size. It
is not resident memory size. The actual stack size per thread seems to be only affected by
local variables and function invocations.

As a result, I guess that the memory problem is usually caused by outgoing messages kept in
memory =)

Anyway, I attach the patch. The main difference from the previous patch is that the default
number of thread pool is set to the number of workers - 1 if  unset. Besides, I added more
comments.

The unit tests are passed against the real hadoop cluster.
                
> 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, GIRAPH-12_3.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