Interface to adjust process limits

[pspillai]

There does not appear to be a way to adjust the number of user processes limits in Autloab jobs. It seems to be hard coded to 100. It would be useful to allow either grading scripts to set the desired limits or to provide a web interface to override the defaults.

This is important because in Linux, threads also count against process limits. As an example, I am teaching a distributed systems course that uses Java and JavaRMI. For a scalability lab, we may require 10s of processes acting like nodes in a large distributed system. Each uses JavaRMI, and will create dozens of worker threads. This easily exceeds the hard limits in Autolab.

In the past, we overcame this issue by using a custom VM that set a different limit on startup. I'm not sure how this limit is implemented in the Docker version. If the limit is set from within the container, one simple fix is to use soft limits (ulimit -S) in setting limits. So, if a grading script really needs to allow more processes/threads, then it can override the soft limit.

[droh]

I've forwarded this to autolab-help@andrew.cmu.edu

On Mon, Feb 15, 2016 at 12:45 PM, pspillai notifications@github.com wrote:

There does not appear to be a way to adjust the number of user processes
limits in Autloab jobs. It seems to be hard coded to 100. It would be
useful to allow either grading scripts to set the desired limits or to
provide a web interface to override the defaults.

This is important because in Linux, threads also count against process
limits. As an example, I am teaching a distributed systems course that uses
Java and JavaRMI. For a scalability lab, we may require 10s of processes
acting like nodes in a large distributed system. Each uses JavaRMI, and
will create dozens of worker threads. This easily exceeds the hard limits
in Autolab.

In the past, we overcame this issue by using a custom VM that set a
different limit on startup. I'm not sure how this limit is implemented in
the Docker version. If the limit is set from within the container, one
simple fix is to use soft limits (ulimit -S) in setting limits. So, if a
grading script really needs to allow more processes/threads, then it can
override the soft limit.

—
Reply to this email directly or view it on GitHub
#630.

[TheodorJ]

Sounds useful, and definitely doesn't exist yet. Leaving this open.