You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Arun C Murthy (JIRA)" <ji...@apache.org> on 2008/04/18 19:34:21 UTC

[jira] Commented: (HADOOP-3280) virtual address space limits break streaming apps

    [ https://issues.apache.org/jira/browse/HADOOP-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590531#action_12590531 ] 

Arun C Murthy commented on HADOOP-3280:
---------------------------------------

I guess HADOOP-2765 missed the use case that the 32-bit/64-bit java Map-Reduce framework could inter-op with 32-bit/64-bit streaming/pipes processes... but we *do* need to set a limit, and cannot rely on the pipes/streaming task to do it - many apps don't and then proceed to hog the cluster.

Should we just add another config called mapred.child.ulimit? (sigh! I know I don't want to do this... *smile*)

For now (i.e. for 0.17.0) mapred.child.ulimit could just provide the memory limit, in future we can probably extend it to be a comma-separated list of key/value pairs for memory, cpu, open files etc.

Thoughts?

> virtual address space limits break streaming apps
> -------------------------------------------------
>
>                 Key: HADOOP-3280
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3280
>             Project: Hadoop Core
>          Issue Type: Bug
>          Components: contrib/streaming
>            Reporter: Rick Cox
>            Priority: Blocker
>             Fix For: 0.17.0
>
>
> HADOOP-2765 added a mandatory, hard virtual address space limit to streaming apps based on the Java process's -Xmx setting.
> This makes it impossible to run a 64-bit streaming app that needs large address spaces under a 32-bit JVM, even if one is otherwise willing to dramatically increase the -Xmx setting without cause. Also, unlike Java's -Xmx limit, the virtual address space limit for an arbitrary UNIX process does not necessarily correspond to RAM usage, so it's likely to be a relatively difficult to configure limit.
> 2765 was originally opened to allow an optional wrapper script around streaming tasks, one use case for which was setting a ulimit. That approach seems much less intrusive and more flexible than the final implementation. The ulimit can also be trivially set by the streaming task itself without any support from Hadoop.
> Marking this as an 0.17 blocker because it will break deployed apps and there is no workaround available.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.