From 788dc77793b60345e1ef38a2881bef1b7c07005c Mon Sep 17 00:00:00 2001 From: Bouwe Andela Date: Thu, 30 May 2024 12:40:03 +0200 Subject: [PATCH] Updates --- _episodes/11-dask-configuration.md | 274 +++++++++++++++++++++++++---- 1 file changed, 238 insertions(+), 36 deletions(-) diff --git a/_episodes/11-dask-configuration.md b/_episodes/11-dask-configuration.md index b70be4cc..076cb3ac 100644 --- a/_episodes/11-dask-configuration.md +++ b/_episodes/11-dask-configuration.md @@ -1,27 +1,34 @@ --- -title: "Dask Configuration" -teaching: 10 -exercises: 10 +title: "Configuring Dask" +teaching: 20 (+ optional 10) +exercises: 40 (+ optional 20) compatibility: ESMValCore v2.10.0 questions: -- What is the [Dask](https://www.dask.org/) configuration file and how should I use it? + - "What is the Dask configuration file and how should I use it?" + - "What are Dask workers" + - "What is the Dask scheduler" objectives: -- Understand the contents of the dask.yml file -- Prepare a personalized dask.yml file -- Configure ESMValCore to use some settings + - "Understand the contents of the dask.yml file" + - "Prepare a personalized dask.yml file" keypoints: -- The ``dask.yml`` file tells ESMValCore how to configure Dask. -- "``client`` can be used to an already running Dask cluster." -- "``cluster`` can be used to start a new Dask cluster for each run." -- "The Dask default scheduler can be configured by editing the files in ~/.config/dask." + - "The ``~/.esmvaltool/dask.yml`` file tells ESMValCore how to configure Dask." + - "``cluster`` can be used to start a new Dask cluster for each run." + - "``client`` can be used to connect to an already running Dask cluster." + - "The Dask default scheduler can be configured by editing the files in ``~/.config/dask``." + - "The Dask Dashboard can be used to see if the Dask workers have sufficient memory available." --- ## The Dask configuration file +When processing larger amounts of data, and especially when the tool crashes +when running a recipe because there is not enough memory available, it is +usually beneficial to change the default +[Dask configuration](https://docs.esmvaltool.org/projects/ESMValCore/en/latest/quickstart/configure.html#dask-configuration). + The preprocessor functions in ESMValCore use the [Iris](https://scitools-iris.readthedocs.io) library, which in turn uses Dask Arrays to be able to process datasets that are larger than the available memory. @@ -31,37 +38,51 @@ but if you are interested there is a [guide to "Lazy Data"](https://scitools-iris.readthedocs.io/en/stable/userguide/real_and_lazy_data.html) available. Lazy data is the term the Iris library uses for Dask Arrays. + +### Workers The most important concept to understand when using Dask Arrays is the concept -of a Dask "worker". With Dask, computations are run in parallel by Python -processes or threads called "workers". These could be on the +of a Dask "worker". With Dask, computations are run in parallel by little programs +that are called "workers". These could be on running on the same machine that you are running ESMValTool on, or they could be on one or -more other computers. Dask workers typically require 2 to 4 gigabytes of +more other computers. Dask workers typically require 2 to 4 gigabytes (GiB) of memory (RAM) each. In order to avoid running out of memory, it is important to use only as many workers as your computer(s) have memory for. ESMValCore (or Dask) provide configuration files where you can configure the number of workers. +Note that only array computations are run using Dask, so total runtime may not +decrease as much as you might expect when you increase the number of Dask +workers. + +### Scheduler + In order to distribute the computations over the workers, Dask makes use of a "scheduler". There are two different schedulers available. The default scheduler can be good choice for smaller computations that can run on a single computer, while the scheduler provided by the Dask Distributed -package is more suitable for larger computations. +package is more suitable for larger computations. > ## On using ``max_parallel_tasks`` > > In the config-user.yml file, there is a setting called ``max_parallel_tasks``. +> Any variable or diagnostic script in the recipe is considered a 'task' in this +> context and when settings this to a value larger than 1, these will be processed +> in parallel on the computer running the ``esmvaltool`` command. +> > With the Dask Distributed scheduler, all the tasks running in parallel > can use the same workers, but with the default scheduler each task will -> start its own workers. For recipes that process large datasets, it is usually -> beneficial to set ``max_parallel_tasks: 1``, while for recipes that process -> many small datasets it can be beneficial to increasing this number. +> start its own workers. If a recipe does not run with ``max_parallel_tasks`` set +> to a value larger than 1, try reducing the value or setting it to 1. This is +> especially the case for recipes with high resolution data or many datasets +> per variable. > {: .callout} ## Starting a Dask distributed cluster +The workers and the scheduler together are called a Dask "cluster". Let's start the the tutorial by configuring ESMValCore so it runs its -computations using 2 workers. +computations on a cluster with just one worker. We use a text editor called ``nano`` to edit the configuration file: @@ -86,13 +107,13 @@ cluster: memory_limit: 4GiB ``` -This tells ESMValCore to start a cluster of one worker, that can use 2 +This tells ESMValCore to start a new cluster of one worker, that can use 2 gigabytes (GiB) of memory and run computations using 2 threads. For a more extensive description of the available arguments and their values, see [``distributed.LocalCluster``](https://distributed.dask.org/en/stable/api.html#distributed.LocalCluster). To see this configuration in action, run we will run a version -of [recipe_easy_ipcc.yml](https://docs.esmvaltool.org/en/latest/recipes/recipe_examples.html) with just two datasets. Download +of [recipe_easy_ipcc.yml](https://docs.esmvaltool.org/en/latest/recipes/recipe_examples.html) with just two datasets. This recipe takes a few minutes to run, once you have the data available. Download the recipe [here](../files/recipe_easy_ipcc_short.yml) and run it with the command: @@ -112,21 +133,18 @@ Open the Dashboard link in a browser to see the Dask Dashboard website. When the recipe has finished running, the Dashboard website will stop working. The top left panel shows the memory use of each of the workers, the panel on the right shows one row for each thread that is doing work, and the panel at the -bottom shows the progress. +bottom shows the progress of all work that the scheduler currently has been asked +to do. > ## Explore what happens if workers do not have enough memory > > Reduce the amount of memory that the workers are allowed to use to 2GiB and -> run the recipe again. Note that the bars representing the memory use turn -> orange as the worker reaches the maximum amount of memory it is -> allowed to use and starts 'spilling' (writing data temporarily) to disk. -> The red blocks in the top right panel represent time spent reading/writing -> to disk. +> run the recipe again. Watch what happens. > >> ## Solution >> >> We use `memory_limit` entry in the `~/.esmvaltool/dask.yml` file to set the ->> amount of memory allowed to 2 gigabytes: +>> amount of memory allowed to 2GiB: >>```yaml >> cluster: >> type: distributed.LocalCluster @@ -134,6 +152,12 @@ bottom shows the progress. >> threads_per_worker: 2 >> memory_limit: 2GiB >>``` +>> Note that the bars representing the memory use turn +>> orange as the worker reaches the maximum amount of memory it is +>> allowed to use and it starts 'spilling' (writing data temporarily) to disk. +>> The red blocks in the top right panel represent time spent reading/writing +>> to disk. While 2 GiB per worker may be enough in other cases, it is apparently +>> not enough for this recipe. >> > {: .solution} {: .challenge} @@ -141,18 +165,20 @@ bottom shows the progress. > ## Tune the configuration to your own computer > -> Look at how much memory you have available on your machine (run the command -> ``grep MemTotal /proc/meminfo`` on Linux), set the ``memory_limit`` back to -> 4 GiB and increase the number of Dask workers so they use total amount -> available minus a few gigabytes for your other work. +> Look at how much memory you have available on your machine (e.g. by running +> the command ``grep MemTotal /proc/meminfo`` on Linux), set the +> ``memory_limit`` back to 4 GiB per worker and increase the number of Dask +> workers so they use total amount available minus a few gigabytes for your +> other work. Run the recipe again and notice that it completed faster. > >> ## Solution >> ->> For example, if your computer has 16 GiB of memory, it can comfortably use ->> 12 GiB of memory for Dask workers, so you can start 3 workers with 4 GiB ->> of memory each. +>> For example, if your computer has 16 GiB of memory and you do not have too +>> many other programs running, it can use 12 GiB of memory for Dask workers, +>> so you can start 3 workers with 4 GiB of memory each. +>> >> Use the `num_workers` entry in the `~/.esmvaltool/dask.yml` file to set the ->> number of workers to 3. +>> number of workers to 3: >>```yaml >> cluster: >> type: distributed.LocalCluster @@ -160,6 +186,182 @@ bottom shows the progress. >> threads_per_worker: 2 >> memory_limit: 4GiB >>``` +>> and run the recipe again with the command ``esmvaltool run recipe_easy_ipcc_short.yml``. The time it took to run the recipe is printed +>> to the screen. +>> +> {: .solution} +{: .challenge} + +## Using an existing Dask Distributed cluster + +In some cases, it can be useful to start the Dask Distributed cluster before +running the ``esmvaltool`` command. For example, if you would like to keep the Dashboard available for further investigation after the recipe completes running, or if you are working from a Jupyter notebook environment, see +[dask-labextension](https://github.com/dask/dask-labextension) and +[dask_jobqueue interactive use](https://jobqueue.dask.org/en/latest/interactive.html) +for more information. + +To use a cluster that was started in some other way, the following configuration +can be used in ``~/.esmvaltool/dask.yml``: + +```yaml +client: + address: "tcp://127.0.0.1:33041" +``` +where the address depends on the Dask cluster. Code to start a +[``distributed.LocalCluster``](https://distributed.dask.org/en/stable/api.html#distributed.LocalCluster) that automatically scales between 0 and 2 workers, depending on demand, could look like this: + +```python +from time import sleep + +from distributed import LocalCluster + +if __name__ == '__main__': # Remove this line when running from a Jupyter notebook + cluster = LocalCluster( + threads_per_worker=2, + memory_limit='4GiB', + ) + cluster.adapt(minimum=0, maximum=2) + + # Print connection information + print(f"Connect to the Dask Dashboard by opening {cluster.dashboard_link} in a browser.") + print("Add the following text to ~/.esmvaltool/dask.yml to connect to the cluster:" ) + print("client:") + print(f' address: "{cluster.scheduler_address}"') + + # When running this as a Python script, the next two lines keep the cluster + # running for an hour. + hour = 3600 # seconds + sleep(1 * hour) + + # Stop the cluster when you are done with it. + cluster.close() +``` + +> ## Start a cluster and use it +> +> Copy the Python code above into a file called ``start_dask_cluster.py`` (or +into a Jupyter notebook if you prefer) and start the cluster using the command +``python start_dask_cluster.py``. Edit the ``~/esmvaltool/dask.yml`` file so +ESMValCore can connect to the cluster. Run the recipe again and notice that the +Dashboard remains available after the recipe completes. +> +>> ## Solution +>> +>> If the script printed +>> ``` +>> Connect to the Dask Dashboard by opening http://127.0.0.1:8787/status in a browser. +>> Add the following text to ~/.esmvaltool/dask.yml to connect to the cluster: +>> client: +>> address: "tcp://127.0.0.1:34827" +>> ``` +>> to the screen, edit the file ``~/.esmvaltool/dask.yml`` so it contains the +lines +>> ```yaml +>> client: +>> address: "tcp://127.0.0.1:34827" +>> ``` +>> open the link "http://127.0.0.1:8787/status" in your browser and +>> run the recipe again with the command ``esmvaltool run recipe_easy_ipcc_short.yml``. +> {: .solution} +{: .challenge} + +When running from a Jupyter notebook, don't forget to `close()` the cluster +when you are running on an HPC facility (see below), to avoid wasting +compute hours you are not using. + +## Using the Dask default scheduler + +It is recommended to use the Distributed scheduler explained above for +processing larger amounts of data. However, in many cases the default scheduler +is good enough. Note that it does not provide a Dashboard, so it is less +instructive and that is why we did not use it earlier in this tutorial. + +To use the default scheduler, comment out all the contents of +``~/.esmvaltool/dask.yml`` and create a file in ``~/.config/dask``, e.g. called +``~/.config/dask/default.yml`` but the filename does not matter, with the +contents: +```yaml +scheduler: threads +num_workers: 4 +``` +to set the number of workers to 4. The ``scheduler`` can also be set to +``synchronous``. In that case it will use a single thread, which may be useful +for debugging. + +> ## Use the default scheduler +> +> Follow the instructions above to use the default scheduler and run the recipe +> again. To keep track of the amount of memory used by the process, you can +> start the ``top`` command in another terminal. The amount of memory is shown +> in the ``RES`` column. +> +>> ## Solution +>> +>> The recipe runs a bit faster with this configuration and you may have seen +>> a memory use of around 5 GB. +>> +> {: .solution} +{: .challenge} + +## Optional: Using dask_jobqueue to run a Dask Cluster on an HPC system + +The [``dask_jobqueue``](https://jobqueue.dask.org) package provides functionality +to start Dask Distributed clusters on High Performance Computing (HPC) or +High Throughput Computing (HTC) systems. This section is optional and only +useful if you have access to a such a system. + +An example configuration for the +[Levante HPC system](https://docs.dkrz.de/doc/levante/index.html) +could look like this: + +```yaml +cluster: + type: dask_jobqueue.SLURMCluster # Levante uses SLURM as a job scheduler + queue: compute # SLURM partition name + account: bk1088 # SLURM account name + cores: 128 # number of CPU cores per SLURM job + memory: 240GiB # amount of memory per SLURM job + processes: 64 # number of Dask workers per SLURM job + interface: ib0 # use the infiniband network interface for communication + local_directory: "/scratch/username/dask-tmp" # directory for spilling to disk + n_workers: 64 # total number of workers to start +``` + +In this example we use the popular SLURM scheduduler, but other schedulers are also supported, see [this list](https://jobqueue.dask.org/en/latest/api.html). + +In the above example, ESMValCore will start 64 Dask workers +(with 128 / 64 = 2 threads each) and for that it will need to launch a single SLURM +batch job on the ``compute`` partition. If you would set ``n_workers`` to e.g. +256, it would launch 4 SLURM batch jobs which would each start 64 workers for a +total of 4 x 64 = 256 workers. In the above configuration, each worker is +allowed to use 240 GiB per job / 64 workers per job = ~4 GiB per worker. + +It is important to read the documentation about your HPC system and answer questions such as +- Which batch scheduler does my HPC system use? +- How many CPU cores are available per node (a computer in an HPC system)? +- How much memory is available for use per node? +- What is the fastest network interface (infiniband is much faster than ethernet)? +- What path should I use for storing temporary files on the nodes (try to avoid slower network storage if possible)? +- Which computing queue has the best availability? +- Can I use part of a node or do I need to use the full node? + - If you are always charged for using the full node, asking for only part of a node is wasteful of computational resources. + - If you can ask for part of a node, make sure the amount of memory you request matches the number of CPU cores if possible, or you will be charged for a larger fraction of the node. + +in order to find the optimal configuration for your situation. + +> ## Tune the configuration to your own computer +> +> Answer the questions above and create an ``~/.esmvaltool/dask.yml`` file that +> matches your situation. To benefit from using an HPC system, you will probably +> need to run a larger recipe than the example we have used so far. You could +> try the full version of that recipe (``esmvaltool run examples/recipe_easy_ipcc.yml``) or use your own recipe. To understand performance, you may want +> to experiment with different configurations. +> +>> ## Solution +>> +>> The best configuration depends on the HPC system that you are using. +>> Discuss your answer with the instructor and the class if possible. If you are +>> taking this course by yourself, you can have a look at the [Dask configuration examples in the ESMValCore documentation](https://docs.esmvaltool.org/projects/ESMValCore/en/latest/quickstart/configure.html#dask-distributed-configuration). >> > {: .solution} {: .challenge}