Checking in here. Any luck? I noticed your comment in https://github.com/dask/distributed/issues/1736 but that seems to be a separate issue about file-based locks rather than about task scheduling priorities. Is the file-based locking stuff getting in the way of you checking for low-memory use?

@rabernat you shouldn't need the spill to disk comment above, just things on master branches. Ideally you would try your clmatology computation again and see if memory use continues to exceed expectations.

The relevant PRs have been merged into master on both repositories.

@rabernat I recommend trying with a combination of these two PRs. These do well for me on the problem listed above.

• https://github.com/dask/dask/pull/3066
• https://github.com/dask/distributed/pull/1730

There is still some memory requriement, but it seems to be under better control

Or, this might work in conjunction with https://github.com/dask/dask/pull/3066

python diff --git a/distributed/worker.py b/distributed/worker.py index a1b9f32..62b5f07 100644 --- a/distributed/worker.py +++ b/distributed/worker.py @@ -1227,8 +1227,8 @@ class Worker(WorkerBase): def add_task(self, key, function=None, args=None, kwargs=None, task=None, who_has=None, nbytes=None, priority=None, duration=None, resource_restrictions=None, **kwargs2): - if isinstance(priority, list): - priority.insert(1, self.priority_counter) + # if isinstance(priority, list): + # priority.insert(1, self.priority_counter) try: if key in self.tasks: state = self.task_state[key]

Looking at the worker diagnostic page during execution is informative. It has a ton of work that it can do and a ton of communication that it can do (to share results with other workers to compute the reductions). In this example it's able to start new work much faster than it is able to communicate results to peers, leading to significant buildup. These two processes happen asynchronously without any back-pressure between them, leading to most of the input being produced before it can be reduced and processed.

That's my current guess anyway. I could imagine pausing worker threads if there is a heavy communication buildup. I'm not sure how generally valuable this is though.

@rabernat you might also consider turning off spill-to-disk. I suspect that by prioritizing the other mechanisms to slow processing that you'll have a better experience

yaml worker-memory-target: False # target fraction to stay below worker-memory-spill: False # fraction at which we spill to disk worker-memory-pause: 0.80 # fraction at which we pause worker threads worker-memory-terminate: 0.95 # fraction at which we terminate the worker

I encourage you to look at the diagnostic page for one of your workers if you get a chance. This is typically served on port 8789 if that port is open.

This example is an interesting one that was adapted from something that @rabernat produced

```python import dask import xarray as xr import dask.array as da import pandas as pd from tornado import gen

from dask.distributed import Client client = Client(processes=False)

below I create a random dataset that is typical of high-res climate models

size of example can be adjusted up and down by changing shape

dims = ('time', 'depth', 'lat', 'lon') time = pd.date_range('1980-01-01', '1980-12-01', freq='1d') shape = (len(time), 5, 1800, 360)

what I consider to be a reasonable chunk size

chunks = (1, 1, 1800, 360) ds = xr.Dataset({k: (dims, da.random.random(shape, chunks=chunks)) for k in ['u', 'v', 'w']}, coords={'time': time})

create seasonal climatology

ds_clim = ds.groupby('time.week').mean(dim='time')

construct seasonal anomaly

ds_anom = ds.groupby('time.week') - ds_clim

compute variance of seasonal anomaly

ds_anom_var = (ds_anom**2).mean(dim='time') ds_anom_var.compute() ```

It works fine locally with processes=False and poorly with processes=True. If anyone has time to help on this issue I recommend investigating what is different in these two cases. If I had time I would start here by trying to improve our understanding with better visual diagnostics, although just poring over logs might also provide some insight.

(not to sound too rosy though, these problems have had me stumped for a couple days)

Since @mrocklin has made it pretty clear that dask will not automatically solve this for us any time soon, we need to brainstorm some creative ways to make this extremely common use case more friendly with out-of-core data.

That's not entirely true. I've said that delete-and-recompute is unlikely to be resolved in the near future. This is the solution proposed by @shoyer but only one possible solution. The fact that your for loop solution works well is evidence that delete-and-recompute is not necessary to solve this problem in your case. I'm actively working on this at https://github.com/dask/dask/pull/3066 (fortunately paid for by other groups).

Teaching the scheduler to delete-and-recompute is possible but also expensive to implement. I would not expect it near term from me.

```python

monthly climatology

ds_mm = ds.groupby('time.month').mean(dim='time')

anomaly

ds_anom = ds.groupby('time.month')- ds_mm ```

I would actually hope that this would be a little bit nicer than the case in the dask issue, especially if you are chunked by some dimension other than time. In the case that @shoyer points to we're creating a global aggregation value and then applying that to all input data. In @rabernat's case we have at least twelve aggregation points and possibly more if there are other chunked dimensions like ensemble (or lat/lon if you choose to chunk those).