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

Scale cores by memory #60

Open
natefoo opened this issue Apr 9, 2024 · 0 comments
Open

Scale cores by memory #60

natefoo opened this issue Apr 9, 2024 · 0 comments

Comments

@natefoo
Copy link
Member

natefoo commented Apr 9, 2024

For some tools like Kraken2 I'd like to define the core count largely in terms of memory, but I also need to use different core counts depending on the destination. Most of the HPC systems I run on allocate memory strictly by core, so you get either 2GB/core or 4GB/core. If I set a static value for cores, I'm wasting cores.

And then occasionally I get allocated full nodes (either if the required memory is > 128 GB or on one particular HPC system that only allocates full nodes), in this case I may have more cores available than I actually want to use due to the slowdowns or increased memory consumption you get with excessively high core counts.

This results in things like my kraken2 rule, the corresponding native spec for the 2GB/core system:

        submit_native_specification: "--partition=RM-shared --time={time} --nodes=1 --ntasks={int(mem/2)} --mem={int(mem/2)*2000}"

where I also override $GALAXY_SLOTS:

    env:
    - name: GALAXY_SLOTS
      value: "{min(int(mem/2), 64)}"

In general for any large memory tool, static core counts are fairly useless, and I may just prefer to always scale cores off of memory in the destination. I'm curious what others think.

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

No branches or pull requests

1 participant