Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for a per-job memory limit for LSF executor #123

Closed
mfoll opened this issue Apr 1, 2016 · 3 comments
Closed

Allow for a per-job memory limit for LSF executor #123

mfoll opened this issue Apr 1, 2016 · 3 comments
Milestone

Comments

@mfoll
Copy link

mfoll commented Apr 1, 2016

LSF implements both a per-process or a per-job memory limit: https://www.ibm.com/support/knowledgecenter/#!/SSETD4_9.1.3/lsf_config_ref/lsf.conf.lsb_job_memlimit.5.dita

Currently nextflow assumes it's a per-process limit and therefore divides the amount of memory requested by the number of cpus requested (

// LSF specify per-process (per-core) memory limit (in MB)
).

It would be useful to have a flag in the nextflow config file to control for this and avoid dividing if the limit is per-job.

@pditommaso
Copy link
Member

OK. I've uploaded a new snapshot including this patch.

You can switch to the per-job memory limit mode adding the following config setting in your nextflow.config file.

executor {
     perJobMemLimit=true
}

To use this snapshot prepend the variable NXF_VER=0.18.0-SNAPSHOT to your nextflow command line, for example:

NXF_VER=0.18.0-SNAPSHOT nextflow run .. 

Could you please give it a try to verify that this and #124 are working as expected?

@mfoll
Copy link
Author

mfoll commented Apr 4, 2016

Thanks, I just tried and it's working great! Just one thing for #124, when perJobMemLimit=false you should still not divide the memory by the number of cpus for the reservation.

@pditommaso
Copy link
Member

Oops, you are right. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants