Change naming conventions for cores and memory about dask-jobqueue HOT 9 CLOSED

Also a bit tangential but I have to say that when reading the dask-worker --help about --memory-limit, I would have guessed that --memory-limit is about the dask-worker memory limit and not a per-process memory limit.

from dask-jobqueue.

I share your concern: I also feel that keywords are not really intuitive at first.

However I felt this first when starting a Dask cluster without dask-jobqueue, just using custom scripts launching dask-worker command, particularly with the following options you are mentioning:

  --nthreads INTEGER            Number of threads per process.
  --nprocs INTEGER              Number of worker processes.  Defaults to one.
  --memory-limit TEXT           Bytes of memory that the worker can use. This
                                can be an integer (bytes), float (fraction of
                                total system memory), string (like 5GB or
                                5000M), 'auto', or zero for no memory
                                management

--memory-limit is not completely clear here neither...

For dask-jobqueue, I think I would rather stick to the dask-worker command options, but maybe there is something to do here?
Another point, I believe that @jhamman for example does some "over subscription" of cores: declaring something like 16 processes of 4 threads for 32 cores node for instance. But that could be doable with what you propose.

Another solution maybe to have several ways of declaring resources, e.g. both

cluster = FooCluster(threads=4, processes=8, memory="16GB")

and something like

cluster = FooCluster(cores=32, processes=8, overall_memory="128GB")

could be used? No breaking change.

from dask-jobqueue.

I could get behind the cores= and overall_memory= keyword alternatives. Any thoughts on this @jhamman @lesteve ?

from dask-jobqueue.

I don't have particularly strong feelings here. If others think alternative keywords are more descriptive and user friendly, let's move that way. So long as we maintain a reasonable amount of transparency and flexibility.

from dask-jobqueue.

I have to admit I was not particularly aware of these subtleties.

As a naive cluster and dask-jobqueue user, I'd like to easily specify the memory per "scheduler job", because that may determine which queue I will end up in.

For "cores vs threads" I don't have a strong opinion.

Maybe @jakirkham has some opinion based on dask-drmaa?

from dask-jobqueue.

See also https://gitter.im/dask/dask?at=5b05f70296af8f1186c5aa70

from dask-jobqueue.

OK, I'm going to start work on a PR to add two new configuration options:

• cores: the total number of cores that we should endeavor to use

  I hope that cores + processes is a better solution than threads + processes. Hopefully it is easier for people to manipulate

• total_memory: the total amount of memory on a node to use

from dask-jobqueue.

See #86

from dask-jobqueue.

Closed thanks to #86.

from dask-jobqueue.