配置

配置¶

要充分利用 Dask，有时需要用户配置。这可能涉及控制日志详细程度、指定集群配置、提供安全凭据，或生产环境中出现的其他一些选项。

配置可以通过以下方式之一指定

在 ~/.config/dask/ 或 /etc/dask/ 中的 YAML 文件
环境变量，例如 DASK_DISTRIBUTED__SCHEDULER__WORK_STEALING=True
子库中的默认设置

这种组合使得在各种设置下轻松指定配置成为可能，从个人工作站到 IT 强制配置，再到 Docker 镜像。

访问配置¶

dask.config.get(key[, default, config, ...])

从全局配置中获取元素

Dask 的配置系统通常使用 dask.config.get 函数访问。你可以使用 . 进行嵌套访问，例如

>>> import dask
>>> import dask.distributed  # populate config with distributed defaults

>>> dask.config.get("distributed.client") # use `.` for nested access
{'heartbeat': '5s', 'scheduler-info-interval': '2s'}

>>> dask.config.get("distributed.scheduler.unknown-task-duration")
'500ms'

你可能希望检查 dask.config.config 字典，以了解当前系统正在使用的配置。

请注意，get 函数对下划线和连字符的处理是相同的。例如，dask.config.get("temporary-directory") 等同于 dask.config.get("temporary_directory")。

像 "128 MiB" 和 "10s" 这样的值是使用 Utilities 中的函数解析的。

指定配置¶

YAML 文件¶

你可以在 YAML 文件中指定配置值。例如

array:
  chunk-size: 128 MiB

distributed:
  worker:
    memory:
      spill: 0.85  # default: 0.7
      target: 0.75  # default: 0.6
      terminate: 0.98  # default: 0.95

  dashboard:
    # Locate the dashboard if working on a Jupyter Hub server
    link: /user/<user>/proxy/8787/status

这些文件可以存在于以下任意位置

用户主目录中的 ~/.config/dask 目录
Python 本地的 {sys.prefix}/etc/dask 目录
site.PREFIXES 中包含 {prefix} 的 {prefix}/etc/dask 目录
根目录（由 DASK_ROOT_CONFIG 环境变量或默认的 /etc/dask/ 指定）

Dask 会搜索这些目录中的所有 YAML 文件并进行合并，优先使用靠近用户的配置文件而非系统配置文件（优先级遵循上述列表中的顺序）。此外，用户可以使用 DASK_CONFIG 环境变量指定一个路径，该路径在上述列表中的优先级最高。

这些 YAML 文件的内容会被合并，这使得不同的 Dask 子项目（如 dask-kubernetes 或 dask-ml）可以独立管理配置文件，但最终合并到同一个全局配置中。

环境变量¶

你也可以使用环境变量指定配置值，如下所示

export DASK_DISTRIBUTED__SCHEDULER__WORK_STEALING=True
export DASK_DISTRIBUTED__SCHEDULER__ALLOWED_FAILURES=5
export DASK_DISTRIBUTED__DASHBOARD__LINK="/user/<user>/proxy/8787/status"

得到的配置值如下所示

{
    'distributed': {
        'scheduler': {
            'work-stealing': True,
            'allowed-failures': 5
        }
    }
}

Dask 会搜索所有以 DASK_ 开头的环境变量，然后通过转换为小写并将双下划线改为嵌套结构来转换键。

Dask 尝试使用 ast.literal_eval 解析所有值，允许用户使用标准的 Python 语法传递数字和布尔值（例如上面示例中的 True），以及列表、字典等。

环境变量优先于 YAML 文件中找到的配置值。

默认值¶

此外，单个子项目在导入时可能会添加自己的默认值。这些值的优先级总是低于上面提到的 YAML 文件或环境变量。

>>> import dask.config
>>> dask.config.config  # no configuration by default
{}

>>> import dask.distributed
>>> dask.config.config  # New values have been added
{
    'scheduler': ...,
    'worker': ...,
    'tls': ...
}

直接在 Python 中¶

dask.config.set(arg, config, lock, **kwargs)

在上下文管理器中临时设置配置值

配置存储在 dask.config.config 中的普通 Python 字典中，可以使用普通的 Python 操作进行修改。

此外，你可以使用 dask.config.set 函数临时设置配置值。该函数接受一个字典作为输入，并将 "." 解释为嵌套访问。

>>> dask.config.set({'optimization.fuse.ave-width': 4})

此函数也可以用作上下文管理器，以便进行一致的清理。

>>> with dask.config.set({'optimization.fuse.ave-width': 4}):
...     arr2, = dask.optimize(arr)

请注意，set 函数对下划线和连字符的处理是相同的。例如，dask.config.set({'optimization.fuse.ave_width': 4}) 等同于 dask.config.set({'optimization.fuse.ave-width': 4})。

最后，请注意持久化对象在初始化时可能会获取配置设置。为了性能原因，这些设置也可能被缓存。对于 dask.distributed 对象（如 Client、Scheduler、Worker 和 Nanny）尤其如此。

直接从 CLI¶

配置也可以从 CLI 设置和查看。

$ dask config set optimization.fuse.ave-width 4
Updated [optimization.fuse.ave-width] to [4], config saved to ~/dask/dask.yaml

$ dask config get optimization.fuse.ave-width
4

分发配置¶

将整个 Dask 配置打包以便在另一台机器上使用也是可取的。这在一些 Dask 分布式库中用于确保远程组件与本地系统具有相同的配置。

这通常由下游库处理，它们使用 base64 编码通过 DASK_INTERNAL_INHERIT_CONFIG 环境变量传递配置。

`dask.config.serialize`(data)	将配置数据序列化为字符串。
`dask.config.deserialize`(data)	将配置数据反序列化为原始对象。

转换工具¶

可以使用点表示法、YAML 或通过环境变量在线配置 Dask。你可以在下方输入自己的配置项进行相互转换。

警告

此工具旨在提高对不同表示法之间转换的理解，并非完美实现。请仅供参考。

YAML

环境变量

点表示法内联

更新配置¶

操作配置字典¶

`dask.config.merge`(*dicts)	更新一系列嵌套字典
`dask.config.update`(old, new[, priority, ...])	用另一个字典中的值更新嵌套字典
`dask.config.expand_environment_variables`(config)	在嵌套配置字典中展开环境变量

如上所述，配置可以来自许多地方，包括多个 YAML 文件、环境变量和项目默认值。每个来源都提供了一个可能嵌套的配置，如下所示

x = {'a': 0, 'c': {'d': 4}}
y = {'a': 1, 'b': 2, 'c': {'e': 5}}

Dask 将合并这些配置，同时尊重嵌套数据结构和顺序

>>> dask.config.merge(x, y)
{'a': 1, 'b': 2, 'c': {'d': 4, 'e': 5}}

你还可以使用 update 函数就地使用新配置更新现有配置。可以优先考虑其中一个配置。这通常用于更新 dask.config.config 中的全局配置。

dask.config.update(dask.config, new, priority='new')  # Give priority to new values
dask.config.update(dask.config, new, priority='old')  # Give priority to old values

有时，展开存储在配置中的环境变量会很有用。这可以通过 expand_environment_variables 函数完成。

dask.config.config = dask.config.expand_environment_variables(dask.config.config)

刷新配置¶

`dask.config.collect`([paths, env])	从路径和环境变量收集配置
`dask.config.refresh`([config, defaults])	通过重新读取 yaml 文件和环境变量更新配置

如果你更改了环境变量或 YAML 文件，Dask 不会立即看到更改。相反，你可以调用 refresh 来执行配置收集过程并更新默认配置。

>>> dask.config.config
{}

>>> # make some changes to yaml files

>>> dask.config.refresh()
>>> dask.config.config
{...}

此函数使用 dask.config.collect，该函数返回配置而不修改全局配置。你可以使用此函数来确定尚未在配置路径上的特定路径的配置。

>>> dask.config.collect(paths=[...])
{...}

下游库¶

`dask.config.ensure_file`(source[, ...])	如果文件不存在，则将其复制到默认位置
`dask.config.update`(old, new[, priority, ...])	用另一个字典中的值更新嵌套字典
`dask.config.update_defaults`(new[, config, ...])	向配置添加一组新的默认值

下游 Dask 库通常遵循标准约定来使用中央 Dask 配置。本节以虚构项目 dask-foo 为例，提供了集成建议。

下游项目通常遵循以下约定

在其源目录中的 YAML 文件中维护默认配置

setup.py
dask_foo/__init__.py
dask_foo/config.py
dask_foo/core.py
dask_foo/foo.yaml  # <---

将该文件中的配置放在项目的命名空间内

# dask_foo/foo.yaml

foo:
  color: red
  admin:
    a: 1
    b: 2

在 config.py 文件中（或任何地方）加载该默认配置文件并将其更新到全局配置中

# dask_foo/config.py
import os
import yaml

import dask.config

fn = os.path.join(os.path.dirname(__file__), 'foo.yaml')

with open(fn) as f:
    defaults = yaml.safe_load(f)

dask.config.update_defaults(defaults)

通过将其包含在 __init__.py 中，确保此文件在导入时运行
```
# dask_foo/__init__.py

from . import config
```

在 dask_foo 代码中，使用 dask.config.get 函数访问配置值

# dask_foo/core.py

def process(fn, color=dask.config.get('foo.color')):
    ...

你可能还希望确保你的 yaml 配置文件包含在你的包中。这可以通过在 MANIFEST.in 中包含以下行来实现
```
recursive-include <PACKAGE_NAME> *.yaml
```
以及在你的 setup.py 的 setup 调用中包含以下内容
```
from setuptools import setup

setup(...,
      include_package_data=True,
      ...)
```

此过程将配置保留在一个中心位置，同时也将其安全地保存在命名空间内。它将配置文件默认放置在一个易于访问的位置（~/.config/dask/\*.yaml），以便用户可以轻松发现可以更改的内容，但将实际默认值保留在源代码中，以便它们更紧密地跟踪库中的更改。

但是，下游库可能会选择替代解决方案，例如将其配置隔离在其库中，而不是使用全局 dask.config 系统。dask.config 模块中的所有函数也适用于参数，并且不需要改变全局状态。

API¶

dask.config.get(key: str, default: Any = _NoDefault.no_default, config: dict | None = None, override_with: Any = None) → Any[source]¶

从全局配置中获取元素

如果 override_with 不为 None，则此值将直接返回。这对于从 Dask 配置获取 kwarg 默认值很有用。

使用 '.' 进行嵌套访问

另请参阅

dask.config.set

示例

>>> from dask import config
>>> config.get('foo')  
{'x': 1, 'y': 2}

>>> config.get('foo.x')  
1

>>> config.get('foo.x.y', default=123)  
123

>>> config.get('foo.y', override_with=None)  
2

>>> config.get('foo.y', override_with=3)  
3

dask.config.set(arg: Mapping | None = None, config: dict = None, lock: threading.Lock = <unlocked _thread.lock object>, **kwargs)[source]¶

在上下文管理器中临时设置配置值

参数

arg映射或 None，可选: 要设置的配置键值对的映射。
**kwargs: 要设置的其他键值对。如果提供了 arg，则 arg 中设置的值将在 kwargs 中的值之前应用。关键字参数中的双下划线 (__) 将替换为 .，从而轻松设置嵌套值。

另请参阅

dask.config.get

示例

>>> import dask

在上下文中使用映射设置 'foo.bar'。

>>> with dask.config.set({'foo.bar': 123}):
...     pass

在上下文中使用关键字参数设置 'foo.bar'。

>>> with dask.config.set(foo__bar=123):
...     pass

全局设置 'foo.bar'。

>>> dask.config.set(foo__bar=123)  

dask.config.merge(*dicts: collections.abc.Mapping) → dict[source]¶

更新一系列嵌套字典

后面的字典中的值优先于前面的字典中的值

另请参阅

dask.config.update

示例

>>> a = {'x': 1, 'y': {'a': 2}}
>>> b = {'y': {'b': 3}}
>>> merge(a, b)  
{'x': 1, 'y': {'a': 2, 'b': 3}}

dask.config.update(old: dict, new: collections.abc.Mapping, priority: Literal['old', 'new', 'new-defaults'] = 'new', defaults: collections.abc.Mapping | None = None) → dict[source]¶

用另一个字典中的值更新嵌套字典

这类似于 dict.update，但它能够平滑地合并嵌套值

此操作在原地进行，并修改 old

参数

priority: 字符串 {'old', 'new', 'new-defaults'}: 如果是 new（默认），则新字典优先。否则，旧字典优先。如果是 'new-defaults'，则应提供当前默认值的映射。仅当 old 中的值与当前默认值匹配时，才会使用 new 进行更新。

另请参阅

dask.config.merge

示例

>>> a = {'x': 1, 'y': {'a': 2}}
>>> b = {'x': 2, 'y': {'b': 3}}
>>> update(a, b)  
{'x': 2, 'y': {'a': 2, 'b': 3}}

>>> a = {'x': 1, 'y': {'a': 2}}
>>> b = {'x': 2, 'y': {'b': 3}}
>>> update(a, b, priority='old')  
{'x': 1, 'y': {'a': 2, 'b': 3}}

>>> d = {'x': 0, 'y': {'a': 2}}
>>> a = {'x': 1, 'y': {'a': 2}}
>>> b = {'x': 2, 'y': {'a': 3, 'b': 3}}
>>> update(a, b, priority='new-defaults', defaults=d)  
{'x': 1, 'y': {'a': 3, 'b': 3}}

dask.config.collect(paths: list[str] = ['/etc/dask', '/home/docs/checkouts/readthedocs.org/user_builds/dask/envs/latest/etc/dask', '/home/docs/.config/dask'], env: collections.abc.Mapping [str, str] | None = None) → dict[source]¶

从路径和环境变量收集配置

参数

pathslist[str]: 要搜索 yaml 配置文件的路径列表
envMapping[str, str]: 系统环境变量

返回值

config: dict

另请参阅

dask.config.refresh: 收集配置并更新到主配置中

dask.config.refresh(config: dict | None = None, defaults: list[collections.abc.Mapping] = [{'temporary-directory': None, 'visualization': {'engine': None}, 'tokenize': {'ensure-deterministic': False}, 'dataframe': {'backend': 'pandas', 'shuffle': {'method': None, 'compression': None}, 'parquet': {'metadata-task-size-local': 512, 'metadata-task-size-remote': 1, 'minimum-partition-size': 75000000}, 'convert-string': None, 'query-planning': None}, 'array': {'backend': 'numpy', 'chunk-size': '128MiB', 'chunk-size-tolerance': 1.25, 'rechunk': {'method': None, 'threshold': 4}, 'svg': {'size': 120}, 'slicing': {'split-large-chunks': None}, 'query-planning': None}, 'optimization': {'annotations': {'fuse': True}, 'fuse': {'active': None, 'ave-width': 1, 'max-width': None, 'max-height': inf, 'max-depth-new-edges': None, 'rename-keys': True, 'delayed': False}}, 'admin': {'async-client-fallback': None, 'traceback': {'shorten': ['concurrent[\\\\\\/]futures[\\\\\\/]', 'dask[\\\\\\/](base|core|local|multiprocessing|optimization|threaded|utils)\\.py', 'dask[\\\\\\/]array[\\\\\\/]core\\.py', 'dask[\\\\\\/]dataframe[\\\\\\/](core|methods)\\.py', 'dask[\\\\\\/]_task_spec\\.py', 'distributed[\\\\\\/](client|scheduler|utils|worker)\\.py', 'tornado[\\\\\\/]gen\\.py', 'pandas[\\\\\\/]core[\\\\\\/]']}}}, {'distributed': {'version': 2, 'scheduler': {'allowed-failures': 3, 'bandwidth': 100000000, 'blocked-handlers': [], 'contact-address': None, 'default-data-size': '1kiB', 'events-cleanup-delay': '1h', 'idle-timeout': None, 'no-workers-timeout': None, 'work-stealing': True, 'work-stealing-interval': '1s', 'worker-saturation': 1.1, 'rootish-taskgroup': 5, 'rootish-taskgroup-dependencies': 5, 'worker-ttl': '5 minutes', 'preload': [], 'preload-argv': [], 'unknown-task-duration': '500ms', 'default-task-durations': {'rechunk-split': '1us', 'split-shuffle': '1us', 'split-taskshuffle': '1us', 'split-stage': '1us'}, 'validate': False, 'dashboard': {'status': {'task-stream-length': 1000}, 'tasks': {'task-stream-length': 100000}, 'tls': {'ca-file': None, 'key': None, 'cert': None}, 'bokeh-application': {'allow_websocket_origin': ['*'], 'keep_alive_milliseconds': 500, 'check_unused_sessions_milliseconds': 500}}, 'locks': {'lease-validation-interval': '10s', 'lease-timeout': '30s'}, 'http': {'routes': ['distributed.http.scheduler.prometheus', 'distributed.http.scheduler.info', 'distributed.http.scheduler.json', 'distributed.http.health', 'distributed.http.proxy', 'distributed.http.statics']}, 'allowed-imports': ['dask', 'distributed'], 'active-memory-manager': {'start': True, 'interval': '2s', 'measure': 'optimistic', 'policies': [{'class': 'distributed.active_memory_manager.ReduceReplicas'}]}}, 'worker': {'blocked-handlers': [], 'multiprocessing-method': 'spawn', 'use-file-locking': True, 'transfer': {'message-bytes-limit': '50MB'}, 'connections': {'outgoing': 50, 'incoming': 10}, 'preload': [], 'preload-argv': [], 'daemon': True, 'validate': False, 'resources': {}, 'lifetime': {'duration': None, 'stagger': '0 seconds', 'restart': False}, 'profile': {'enabled': True, 'interval': '10ms', 'cycle': '1000ms', 'low-level': False}, 'memory': {'recent-to-old-time': '30s', 'rebalance': {'measure': 'optimistic', 'sender-min': 0.3, 'recipient-max': 0.6, 'sender-recipient-gap': 0.1}, 'transfer': 0.1, 'target': 0.6, 'spill': 0.7, 'pause': 0.8, 'terminate': 0.95, 'max-spill': False, 'spill-compression': 'auto', 'monitor-interval': '100ms'}, 'http': {'routes': ['distributed.http.worker.prometheus', 'distributed.http.health', 'distributed.http.statics']}}, 'nanny': {'preload': [], 'preload-argv': [], 'environ': {}, 'pre-spawn-environ': {'MALLOC_TRIM_THRESHOLD_': 65536, 'OMP_NUM_THREADS': 1, 'MKL_NUM_THREADS': 1, 'OPENBLAS_NUM_THREADS': 1}}, 'client': {'heartbeat': '5s', 'scheduler-info-interval': '2s', 'security-loader': None, 'preload': [], 'preload-argv': []}, 'deploy': {'lost-worker-timeout': '15s', 'cluster-repr-interval': '500ms'}, 'adaptive': {'interval': '1s', 'target-duration': '5s', 'minimum': 0, 'maximum': inf, 'wait-count': 3}, 'comm': {'retry': {'count': 0, 'delay': {'min': '1s', 'max': '20s'}}, 'compression': False, 'shard': '64MiB', 'offload': '10MiB', 'default-scheme': 'tcp', 'socket-backlog': 2048, 'ucx': {'cuda-copy': None, 'tcp': None, 'nvlink': None, 'infiniband': None, 'rdmacm': None, 'create-cuda-context': None, 'environment': {}}, 'zstd': {'level': 3, 'threads': 0}, 'timeouts': {'connect': '30s', 'tcp': '30s'}, 'require-encryption': None, 'tls': {'ciphers': None, 'min-version': 1.2, 'max-version': None, 'ca-file': None, 'scheduler': {'cert': None, 'key': None}, 'worker': {'key': None, 'cert': None}, 'client': {'key': None, 'cert': None}}, 'websockets': {'shard': '8MiB'}}, 'diagnostics': {'nvml': True, 'cudf': False, 'computations': {'max-history': 100, 'nframes': 0, 'ignore-modules': ['asyncio', 'functools', 'threading', 'datashader', 'dask', 'debugpy', 'distributed', 'ipykernel', 'coiled', 'cudf', 'cuml', 'matplotlib', 'pluggy', 'prefect', 'rechunker', 'xarray', 'xgboost', 'xdist', '__channelexec__', 'execnet'], 'ignore-files': ['runpy\\.py', 'pytest', 'py\\.test', 'pytest-script\\.py', '_pytest', 'pycharm', 'vscode_pytest', 'get_output_via_markers\\.py']}, 'erred-tasks': {'max-history': 100}}, 'p2p': {'comm': {'buffer': '1 GiB', 'concurrency': 10, 'message-bytes-limit': '2 MiB', 'retry': {'count': 10, 'delay': {'min': '1s', 'max': '30s'}}}, 'storage': {'buffer': '100 MiB', 'disk': True}, 'threads': None}, 'dashboard': {'link': '{scheme}://{host}:{port}/status', 'export-tool': False, 'graph-max-items': 5000, 'prometheus': {'namespace': 'dask'}}, 'admin': {'large-graph-warning-threshold': '10MB', 'tick': {'interval': '20ms', 'limit': '3s', 'cycle': '1s'}, 'max-error-length': 10000, 'log-length': 10000, 'log-format': '%(asctime)s - %(name)s - %(levelname)s - %(message)s', 'low-level-log-length': 1000, 'pdb-on-err': False, 'system-monitor': {'interval': '500ms', 'log-length': 7200, 'disk': True, 'host-cpu': False, 'gil': {'enabled': True, 'interval': '1ms'}}, 'event-loop': 'tornado'}, 'rmm': {'pool-size': None}}}], **kwargs) → None[source]¶

通过重新读取 yaml 文件和环境变量更新配置

这会改变全局的 dask.config.config，或者如果传入了 config 参数，则改变该参数。

这经历以下阶段

清除所有旧配置
从下游库存储的默认值更新（参见 update_defaults）
从 yaml 文件和环境变量更新
自动重命名已弃用的键（并发出警告）

请注意，某些功能仅在启动时检查一次配置，即使配置发生更改，其行为也可能不会改变。如果方便，建议重新启动 python 进程以确保新的配置更改生效。

另请参阅

dask.config.collect: 对于参数
dask.config.update_defaults

dask.config.ensure_file(source: str, destination: str | None = None, comment: bool = True) → None[source]¶

如果文件不存在，则将其复制到默认位置

如果默认配置文件不存在，此函数会尝试将其移动到默认位置。默认情况下，它也会注释掉该文件。

这供下游模块（如 dask.distributed）使用，这些模块可能有希望包含在默认配置路径中的默认配置文件。

参数

source字符串，文件名: 源配置文件，通常在源目录中。
destination字符串，目录: 目标目录。可通过 DASK_CONFIG 环境变量配置，默认回退到 ~/.config/dask。
comment布尔值，默认为 True: 复制时是否注释掉配置文件。

dask.config.expand_environment_variables(config: Any) → Any[source]¶

在嵌套配置字典中展开环境变量

此函数将递归搜索任何嵌套字典和/或列表。

参数

configdict、iterable 或 str: 输入对象以搜索环境变量

返回值

config与输入类型相同

示例

>>> expand_environment_variables({'x': [1, 2, '$USER']})  
{'x': [1, 2, 'my-username']}

注意

可以通过点号表示法、YAML 或环境变量内联配置 Dask。有关将以下点号表示法转换为其他形式的信息，请参阅转换实用程序。

Dask ¶

temporary-directory None ¶: 本地磁盘存储的临时目录，如 /tmp, /scratch, 或 /local。此目录用于 dask 溢写到磁盘的操作。当值为 "null" (默认) 时，dask 将在 dask 启动的位置创建目录：`cwd/dask-worker-space`

visualization.engine None ¶: 在 Dask 集合上调用 ``.visualize()`` 时使用的可视化引擎。当前支持 ``'graphviz'``、``'ipycytoscape'`` 和 ``'cytoscape'`` (``'ipycytoscape'`` 的别名)

tokenize.ensure-deterministic False ¶: 如果为 ``true``，当无法生成确定性 token 时，tokenize 将报错而不是回退到 uuids。默认为 ``false``。

dataframe.backend pandas ¶: 用于受支持的 dataframe 创建函数的后端。默认为 "pandas"。

dataframe.shuffle.method None ¶: 选择的默认混洗方法。可能的值有 disk、tasks、p2p。如果为 null，则根据应用程序选择最佳方法。

dataframe.shuffle.compression None ¶: 用于磁盘混洗的压缩算法。用于压缩的库 Partd 支持 ZLib、BZ2 和 SNAPPY。

dataframe.parquet.metadata-task-size-local 512 ¶: 从 LOCAL 文件系统读取 parquet 数据集时，每个元数据处理任务中处理的文件数量。指定为 0 将导致在客户端上进行串行执行。

dataframe.parquet.metadata-task-size-remote 1 ¶: 从 REMOTE 文件系统读取 parquet 数据集时，每个元数据处理任务中处理的文件数量。指定为 0 将导致在客户端上进行串行执行。

dataframe.parquet.minimum-partition-size 75000000 ¶: 从 parquet 读取后，单个分区的最小内存大小。较小的 parquet 文件将被合并到单个分区中，以达到此阈值。

dataframe.convert-string None ¶: 是否将类字符串数据转换为 pyarrow 字符串。

dataframe.query-planning None ¶: 是否使用查询规划。

array.backend numpy ¶: 用于受支持的数组创建函数的后端。默认为 "numpy"。

array.chunk-size 128MiB ¶: 默认的目标块大小。默认为 "128MiB"。

array.chunk-size-tolerance 1.25 ¶: 创建输出块时，不同算法的上限容差。默认为 1.25。这意味着算法在此维度上可以超过平均输入块大小 25%。

array.rechunk.method None ¶: 用于重新分块的方法。可能的值有 tasks 或 p2p。如果为 null，则根据应用程序选择最佳方法。

array.rechunk.threshold 4 ¶: 图增长因子，高于此因子时基于任务的混洗会引入中间步骤。

array.svg.size 120 ¶: 将 dask 数组显示为 SVG 图像时使用的像素大小。例如，这用于在 Jupyter notebook 中进行美观渲染。

array.slicing.split-large-chunks None ¶: 切片 Array 时如何处理创建的大块。默认情况下会生成警告。设置为 ``False`` 可静默警告并允许大的输出块。设置为 ``True`` 可静默警告并避免大的输出块。

array.query-planning None ¶: 是否对数组使用查询规划。

optimization.annotations.fuse True ¶: 如果相邻的块级别层具有不同的注解（例如，一个 retry=3，另一个 retry=4），Dask 可以尝试根据一些简单的规则合并这些注解。``retries`` 设置为各层中的最大值，``priority`` 设置为各层中的最大值，``resources`` 设置为所有资源中的最大值，``workers`` 设置为请求的 workers 的交集。如果此设置被禁用，则具有不同注解的相邻块级别层将*不会*被融合。

optimization.fuse.active None ¶: 开启/关闭任务融合。此选项指的是完全具象化任务图（而非高级图）的融合。默认情况下 (None)，对于 Dask-Dataframe 集合，活动任务融合选项将被视为 ``False``；对于所有其他图（包括 Dask-Array 集合），则被视为 ``True``。

optimization.fuse.ave-width 1 ¶: 宽度的上限，其中 width = num_nodes / height，是并行度的良好衡量标准

optimization.fuse.max-width None ¶: 如果总宽度大于此值，则不进行融合。设置为 null 可根据 1.5 + ave_width * log(ave_width + 1) 进行动态调整。

optimization.fuse.max-height inf ¶: 融合层级不超过此数量

optimization.fuse.max-depth-new-edges None ¶: 如果在此层级之后添加了新的依赖项，则不进行融合。设置为 null 可根据 ave_width * 1.5 进行动态调整。

optimization.fuse.rename-keys True ¶: 设置为 true，使用 `default_fused_keys_renamer` 重命名融合后的键。重命名融合后的键可以使图更易于理解和易懂，但这会带来额外的处理成本。如果为 False，则使用最顶层的键。对于高级用法，也接受一个用于创建新名称的函数。

optimization.fuse.delayed False ¶: 是否将相邻的 delayed 调用融合在一起。这有助于确保独立的 delayed 调用链在单个任务中执行，以减少单个 worker 上的内存占用。

admin.async-client-fallback None ¶: 如果不为 null，则在 get_scheduler/compute 中将异步 Client 替换为提供的调度器类型。

admin.traceback.shorten ['concurrent[\\\\\\/]futures[\\\\\\/]', 'dask[\\\\\\/](base|core|local|multiprocessing|optimization|threaded|utils)\\.py', 'dask[\\\\\\/]array[\\\\\\/]core\\.py', 'dask[\\\\\\/]dataframe[\\\\\\/](core|methods)\\.py', 'dask[\\\\\\/]_task_spec\\.py', 'distributed[\\\\\\/](client|scheduler|utils|worker)\\.py', 'tornado[\\\\\\/]gen\\.py', 'pandas[\\\\\\/]core[\\\\\\/]'] ¶: 清理 Dask traceback 以提高可读性。移除所有与列出的正则表达式之一匹配的模块。始终保留第一个和最后一个帧。

分布式客户端 ¶

distributed.client.heartbeat 5s ¶: 此值是心跳之间的时间间隔。客户端向调度器发送周期性心跳消息。如果客户端丢失了足够多的心跳，调度器就会认为它已下线。

distributed.client.scheduler-info-interval 2s ¶: 调度器信息更新之间的间隔

distributed.client.security-loader None ¶: 一个用于为客户端加载安全凭证的回调函数的完全限定名（例如 ``module.submodule.function``）。如果在创建 ``Client`` 时没有显式传递安全对象，则会调用此回调函数，并传入包含客户端信息的字典（目前只有 ``address``），该回调函数应返回一个用于此客户端的 ``Security`` 对象，或返回 ``None`` 以回退到默认安全配置。

distributed.client.preload [] ¶: 在客户端生命周期内运行自定义模块。您可以在客户端启动和关闭时运行自定义模块。有关更多信息，请参阅 https://docs.dask.org.cn/en/latest/how-to/customize-initialization.html

distributed.client.preload-argv [] ¶: 传递给上述 preload 脚本的参数。有关更多信息，请参阅 https://docs.dask.org.cn/en/latest/how-to/customize-initialization.html

分布式通信 (Comm)¶

distributed.comm.retry.count 0 ¶: 重试连接的次数

distributed.comm.retry.delay.min 1s ¶: 两次重试尝试之间的第一个非零延迟

distributed.comm.retry.delay.max 20s ¶: 重试之间的最大延迟

distributed.comm.compression False ¶: 要使用的压缩算法。'auto' 默认使用已安装的 lz4，如果未安装则使用已安装的 snappy，否则使用 false。zlib 和 zstd 只有在此处明确请求时才使用。无论此设置如何，不可压缩数据和 localhost 上的传输始终不压缩。另请参阅 distributed.worker.memory.spill-compression。

distributed.comm.shard 64MiB ¶: 通过通信发送的帧的最大大小。有些网络基础设施不喜欢发送非常大的消息。Dask 通信会将这些大消息切分成许多小消息。此属性决定了这种分片的最大大小。

distributed.comm.offload 10MiB ¶: 消息大小，超过此大小时我们会选择将序列化卸载到另一个线程。在某些情况下，您也可以选择将此值设置为 false 来完全禁用此功能。如果您希望将序列化包含在性能分析数据中，或者如果您具有对反序列化特别敏感的数据类型，则此功能非常有用。

distributed.comm.default-scheme tcp ¶: 要使用的默认协议，如 tcp 或 tls

distributed.comm.socket-backlog 2048 ¶: 在 workers 之间混洗数据时，单个 worker socket 上可能会出现 O(集群大小) 的连接请求，请确保 backlog 足够大以避免丢失任何请求。

distributed.comm.ucx.cuda-copy None ¶: 设置环境变量以通过 UCX 启用 CUDA 支持。即使不支持或禁用了 InfiniBand 和 NVLink，也可以使用此设置，此时数据将通过 TCP 传输。

distributed.comm.ucx.tcp None ¶: 设置环境变量以通过 UCX 启用 TCP 支持，即使不支持或禁用了 InfiniBand 和 NVLink。

distributed.comm.ucx.nvlink None ¶: 设置环境变量以通过 NVLink 启用 UCX 支持，这意味着 ``distributed.comm.ucx.tcp=True``。

distributed.comm.ucx.infiniband None ¶: 设置环境变量以通过 InfiniBand 启用 UCX 支持，这意味着 ``distributed.comm.ucx.tcp=True``。

distributed.comm.ucx.rdmacm None ¶: 设置环境变量以启用 UCX RDMA 连接管理器支持，需要 ``distributed.comm.ucx.infiniband=True``。

distributed.comm.ucx.create-cuda-context None ¶: 在 UCX 初始化之前创建一个 CUDA 上下文。这对于使 UCX 能够正确识别具有专用网络硬件（如 InfiniBand）的 GPU 的连接性是必需的。这允许 UCX 自动选择传输方式，无需为每种传输方式指定额外的变量，同时确保最优连接性。当为 ``True`` 时，将在 ``CUDA_VISIBLE_DEVICES`` 中列出的第一个设备上创建一个 CUDA 上下文。

distributed.comm.zstd.level 3 ¶: 压缩级别，介于 1 和 22 之间。

distributed.comm.zstd.threads 0 ¶: 要使用的线程数。0 表示单线程，-1 表示从 CPU 数量推断。

distributed.comm.timeouts.connect 30s ¶: 无注释

distributed.comm.timeouts.tcp 30s ¶: 无注释

distributed.comm.require-encryption None ¶: 是否要求对非本地通信进行加密

distributed.comm.tls.ciphers None ¶: 允许的密码套件，指定为 OpenSSL 密码字符串。

distributed.comm.tls.min-version 1.2 ¶: 支持的最低 TLS 版本。默认为 TLS 1.2。

distributed.comm.tls.max-version None ¶: 支持的最大 TLS 版本。默认为平台支持的最大版本。

distributed.comm.tls.ca-file None ¶: CA 文件的路径，pem 格式

distributed.comm.tls.scheduler.cert None ¶: 证书文件路径

distributed.comm.tls.scheduler.key None ¶: 密钥文件路径。或者，密钥可以附加到上面的证书文件中，此时此字段留空。

distributed.comm.tls.worker.key None ¶: 密钥文件路径。或者，密钥可以附加到上面的证书文件中，此时此字段留空。

distributed.comm.tls.worker.cert None ¶: 证书文件路径

distributed.comm.tls.client.key None ¶: 密钥文件路径。或者，密钥可以附加到上面的证书文件中，此时此字段留空。

distributed.comm.tls.client.cert None ¶: 证书文件路径

distributed.comm.websockets.shard 8MiB ¶: 通过通信发送的 websocket 帧的最大大小。这与 distributed.comm.shard 有些重复，但 websockets 的最大消息大小通常比其他协议小得多，因此此属性用于设置较小的默认分片大小，并允许单独控制 websocket 消息分片。

分布式仪表板 ¶

distributed.dashboard.link {scheme}://{host}:{port}/status ¶: 仪表板链接的形式。这用于打印仪表板链接的任何地方。它会填入相关信息，如协议、主机和端口号。

distributed.dashboard.export-tool False ¶: 无注释

distributed.dashboard.graph-max-items 5000 ¶: 在“图”视图中尝试绘制的最大任务数

distributed.dashboard.prometheus.namespace dask ¶: 用于所有 prometheus 指标的命名空间前缀。

分布式部署 ¶

distributed.deploy.lost-worker-timeout 15s ¶: 丢失的 worker 作业强制关闭的间隔时间。否则，我们会等待一段时间，看看 worker 是否会重新出现。

distributed.deploy.cluster-repr-interval 500ms ¶: 更新 widget 的 cluster-repr 的调用之间的间隔

分布式调度器 ¶

distributed.scheduler.allowed-failures 3 ¶: 任务被视为“坏”之前允许的重试次数。当 worker 在运行任务时死亡，该任务会在其他地方重新运行。如果许多 worker 在运行同一个任务时死亡，我们称该任务为“坏”任务，并抛出 KilledWorker 异常。这是在此任务被标记为“坏”之前允许死亡的 worker 数量。

distributed.scheduler.bandwidth 100000000 ¶: 任意一对 workers 之间的预期带宽。这用于制定调度决策。调度器将使用此值作为基线，但也会随时间学习它。

distributed.scheduler.blocked-handlers [] ¶: 要排除的处理程序列表。调度器通过接收来自不同 workers 和客户端的消息，然后根据这些消息执行操作。每条消息都有一个操作，例如“close-worker”或“task-finished”。在某些高安全性的情况下，管理员可以选择阻止某些处理程序运行。这些处理程序可以在此处列出。有关处理程序列表，请参阅 `dask.distributed.Scheduler.handlers` 属性。

distributed.scheduler.contact-address None ¶: 调度器向 workers 广播用于与其通信的地址。当调度器绑定的地址不能与 workers 用于联系调度器的地址相同时（例如，因为前者是私有地址，并且调度器与 workers 位于不同的网络中），需要指定此地址。

distributed.scheduler.default-data-size 1kiB ¶: 如果我们对一块数据一无所知时的默认大小。这在调度器的一些调度决策中使用。

distributed.scheduler.events-cleanup-delay 1h ¶: 在 workers 或客户端从调度器中移除后，等待多长时间将其从事件日志中移除的时间。

distributed.scheduler.idle-timeout None ¶: 如果在该持续时间内没有活动发生，则关闭调度器。

distributed.scheduler.no-workers-timeout None ¶: 处于不可运行状态任务的超时时间。如果任务在此时间内仍不可运行，则失败。仅当任务没有挂起依赖项，并且任务的限制未被任何可用 worker 满足或根本没有 worker 运行时，任务才被视为不可运行。在自适应集群中，此超时时间必须设置得比 worker 启动所需的时间安全地长。

distributed.scheduler.work-stealing True ¶: 是否动态地在 workers 之间平衡工作负载。有时某个 worker 的工作量超出预期。调度器默认会根据需要移动这些任务。将其设置为 false 可禁用此行为。

distributed.scheduler.work-stealing-interval 1s ¶: 平衡 worker 负载的频率

distributed.scheduler.worker-saturation 1.1 ¶: 控制发送给 worker 的根任务数量（类似于 `readahead`）。一次最多将 worker-saturation * nthreads 个根任务发送给 worker。如果为 `.inf`，则所有可运行任务将立即发送给 worker。目标数量向上取整，因此任何 `worker-saturation` 值 > 1.0 都保证至少会向 worker 发送一个额外的任务。允许过度饱和 (> 1.0) 意味着 worker 在完成上一个任务后可能会立即开始运行新的根任务，即使有优先级更高的下游任务要运行。这减少了 worker 的空闲时间，让 worker 在等待调度器进一步指令时可以做一些事情，即使这可能不是最有效率的事情。这通常会以增加内存使用量为代价。它会导致图的执行变得“更宽”（更广度优先）。计算密集型工作负载可能会受益于过度饱和。内存密集型工作负载通常应将 `worker-saturation` 保持在 1.0，但如果内存充足，1.25-1.5 的值可以略微提高性能。

distributed.scheduler.rootish-taskgroup 5 ¶: 当设置了 worker saturation 时，控制何时将特定任务组标识为“类根”。如果一个任务组的依赖项数量不超过特定数量（默认为 5），则将其标识为“类根”。对于非常大的数据集，xarray 生成的数据任务数量可能高于 5，此时此判断可能出错。增加此限制可以成功捕获这些根任务，但会增加错误将任务组标识为“类根”的风险，这可能会影响性能。

distributed.scheduler.rootish-taskgroup-dependencies 5 ¶: 控制任务组的传递依赖项数量，以便将其视为“类根”。它检查“类根”任务组的每个依赖项拥有的依赖项数量。与 `rootish-taskgroup` 相同的注意事项适用。

distributed.scheduler.worker-ttl 5 minutes ¶: worker 的生存时间 (TTL)。如果我们在此时间内未收到心跳，则假定 worker 已死亡。

distributed.scheduler.preload [] ¶: 在调度器生命周期内运行自定义模块。您可以在调度器启动和关闭时运行自定义模块。有关更多信息，请参阅 https://docs.dask.org.cn/en/latest/how-to/customize-initialization.html

distributed.scheduler.preload-argv [] ¶: 传递给上述 preload 脚本的参数。有关更多信息，请参阅 https://docs.dask.org.cn/en/latest/how-to/customize-initialization.html

distributed.scheduler.unknown-task-duration 500ms ¶: 所有持续时间未知的任务的默认持续时间。调度器会随着时间学习任务的持续时间。但是，当它第一次遇到新类型的任务时，必须猜测其需要多长时间。此值就是该猜测时间。

distributed.scheduler.default-task-durations.rechunk-split 1us ¶: 无注释

distributed.scheduler.default-task-durations.split-shuffle 1us ¶: 无注释

distributed.scheduler.default-task-durations.split-taskshuffle 1us ¶: 无注释

distributed.scheduler.default-task-durations.split-stage 1us ¶: 无注释

distributed.scheduler.validate False ¶: 执行期间是否运行一致性检查。这通常仅用于调试。

distributed.scheduler.dashboard.status.task-stream-length 1000 ¶: 任务流图中包含的最大任务数

distributed.scheduler.dashboard.tasks.task-stream-length 100000 ¶: 任务流图中包含的最大任务数

distributed.scheduler.dashboard.tls.ca-file None ¶: 无注释

distributed.scheduler.dashboard.tls.key None ¶: 无注释

distributed.scheduler.dashboard.tls.cert None ¶: 无注释

distributed.scheduler.dashboard.bokeh-application.allow_websocket_origin ['*'] ¶: 无注释

distributed.scheduler.dashboard.bokeh-application.keep_alive_milliseconds 500 ¶: 无注释

distributed.scheduler.dashboard.bokeh-application.check_unused_sessions_milliseconds 500 ¶: 无注释

distributed.scheduler.locks.lease-validation-interval 10s ¶: 调度器验证所有已获取租约是否过期的间隔。必须始终小于 lease-timeout 本身。

distributed.scheduler.locks.lease-timeout 30s ¶: 在租约失效并释放之前，等待客户端刷新的最大间隔。

distributed.scheduler.http.routes ['distributed.http.scheduler.prometheus', 'distributed.http.scheduler.info', 'distributed.http.scheduler.json', 'distributed.http.health', 'distributed.http.proxy', 'distributed.http.statics'] ¶: 一个可以根据需要包含或排除的模块列表，如 "prometheus" 和 "health"。这些模块将具有一个 ``routes`` 关键字，该关键字被添加到主要的 HTTP 服务器。这是一个可以扩展用户定义模块的列表。

distributed.scheduler.allowed-imports ['dask', 'distributed'] ¶: 调度器允许导入的受信任根模块列表（包括子模块）。出于安全考虑，调度器不允许导入任意 Python 模块。

distributed.scheduler.active-memory-manager.start True ¶: 设置为 true 以在调度器初始化时自动启动 AMM

distributed.scheduler.active-memory-manager.interval 2s ¶: 时间表达式，例如 "2s"。每隔此时间运行 AMM 周期.

distributed.scheduler.active-memory-manager.measure optimistic ¶: distributed.scheduler.MemoryState 的属性之一

distributed.scheduler.active-memory-manager.policies [{'class': 'distributed.active_memory_manager.ReduceReplicas'}] ¶: 无注释

分布式 Worker ¶

distributed.worker.blocked-handlers [] ¶: 要排除的处理程序列表。调度器通过接收来自不同 workers 和客户端的消息，然后根据这些消息执行操作。每条消息都有一个操作，例如“close-worker”或“task-finished”。在某些高安全性的情况下，管理员可以选择阻止某些处理程序运行。这些处理程序可以在此处列出。有关处理程序列表，请参阅 `dask.distributed.Scheduler.handlers` 属性。

distributed.worker.multiprocessing-method spawn ¶: 如何创建新的 worker，可以是 "spawn"、"forkserver" 或 "fork" 之一。此值会传递给 ``multiprocessing.get_context`` 函数。

distributed.worker.use-file-locking True ¶: 创建 workers 时是否使用锁文件。Workers 会创建一个本地目录用于存放临时文件。当在同一进程上同时创建许多 workers 时，这些 workers 可能因为同时尝试创建该目录而相互冲突。为了避免这种情况，Dask 通常使用基于文件的锁。然而，在某些系统上，基于文件的锁不起作用。这在 HPC NFS 系统上尤为常见，用户可能希望将此值设置为 false。

distributed.worker.transfer.message-bytes-limit 50MB ¶: worker 在单个 gather 操作中从另一个 worker 请求的最大数据量。任务是分批 gather 的，如果批次中的第一个任务大于此值，该任务仍将被 gather 以确保进度。因此，此限制不是绝对的。请注意，此限制适用于单个 gather 操作，并且 worker 可以并行地从多个 workers gather 数据。

distributed.worker.connections.outgoing 50 ¶: 无注释

distributed.worker.connections.incoming 10 ¶: 无注释

distributed.worker.preload [] ¶: 在 worker 生命周期内运行自定义模块。您可以在 worker 启动和关闭时运行自定义模块。有关更多信息，请参阅 https://docs.dask.org.cn/en/latest/how-to/customize-initialization.html

distributed.worker.preload-argv [] ¶: 传递给上述 preload 脚本的参数。有关更多信息，请参阅 https://docs.dask.org.cn/en/latest/how-to/customize-initialization.html

distributed.worker.daemon True ¶: 是否将我们的进程作为守护进程运行

distributed.worker.validate False ¶: 执行期间是否运行一致性检查。这通常仅用于调试。

distributed.worker.lifetime.duration None ¶: worker 创建后关闭的时间，例如“1 hour”

distributed.worker.lifetime.stagger 0 seconds ¶: 错开 worker 生命周期的随机量。如果您同时创建许多 workers，您可能希望避免它们同时自行关闭。为了避免这种情况，您可以设置一个错开时间，使它们在关闭时具有一些随机变化，例如“5 minutes”。这样，一些 workers 可能会死亡，新的 worker 可以启动，并且数据可以顺利传输。

distributed.worker.lifetime.restart False ¶: 在生命周期截止日期后，我们是否尝试复活 worker？

distributed.worker.profile.enabled True ¶: 是否启用性能分析

distributed.worker.profile.interval 10ms ¶: 轮询 worker 线程之间的时间间隔，通常很短，例如 10ms

distributed.worker.profile.cycle 1000ms ¶: 将此数据捆绑在一起并发送到调度器之间的时间。这控制了用户可以在时间轴上查询性能分析信息的粒度。

distributed.worker.profile.low-level False ¶: 是否使用 libunwind 和 stacktrace 库在较低级别（Python 之下）收集性能分析信息。为了使其工作，您需要在 conda install -c numba stacktrace 安装实验性的 stacktrace 库。请参阅 https://github.com/numba/stacktrace

distributed.worker.memory.recent-to-old-time 30s ¶: 当进程内存（操作系统观察到）增加，且这些增加量并非由 worker 上存储的 dask 键导致时，在此时间内忽略它，然后再在非时间敏感的启发式方法中考虑它。此时间应设置得比大多数 dask 任务的持续时间更长。

distributed.worker.memory.rebalance.measure optimistic ¶: 应使用 distributed.scheduler.MemoryState 的哪个属性来衡量 worker 内存使用情况

distributed.worker.memory.rebalance.sender-min 0.3 ¶: worker 进程内存的比例，达到此比例时我们可能开始将数据传输到其他 workers。

distributed.worker.memory.rebalance.recipient-max 0.6 ¶: worker 进程内存的比例，达到此比例时我们可能停止接收来自其他 workers 的数据。当 max_memory 未设置时，此值被忽略。

distributed.worker.memory.rebalance.sender-recipient-gap 0.1 ¶: worker 进程内存的比例，围绕集群平均值，当进行重新平衡操作时，worker 既不是数据发送者也不是接收者。例如，如果集群平均占用率为 50%，sender-recipient-gap=0.1 意味着只有高于 55% 的节点才会提供数据，只有低于 45% 的节点才会接收数据。这有助于避免数据在集群中反复跳动。

distributed.worker.memory.transfer 0.1 ¶: 当接收到的数据传输总大小超过此数量时，我们开始限制接收到的数据传输。

distributed.worker.memory.target 0.6 ¶: 当进程内存（操作系统观察到）超过此数量时，我们开始将持有最旧数据块的 dask 键溢写到磁盘。

distributed.worker.memory.spill 0.7 ¶: 当进程内存（操作系统观察到）超过此数量时，我们开始将数据溢写到磁盘，从持有最旧数据块的 dask 键开始，直到进程内存降至目标阈值以下。

distributed.worker.memory.pause 0.8 ¶: 当进程内存（操作系统观察到）超过此数量时，我们将不再在 worker 上启动新任务或获取新数据。

distributed.worker.memory.terminate 0.95 ¶: 当进程内存达到此级别时，nanny 进程将杀死 worker（如果存在 nanny）。

distributed.worker.memory.max-spill False ¶: 磁盘上溢写的最大字节数限制。

distributed.worker.memory.spill-compression auto ¶: 要使用的压缩算法。'auto' 默认使用已安装的 lz4，如果未安装则使用已安装的 snappy，否则使用 false。zlib 和 zstd 只有在此处明确请求时才使用。无论此设置如何，不可压缩数据始终不压缩。另请参阅 distributed.comm.compression。

distributed.worker.memory.monitor-interval 100ms ¶: 检查溢写、暂停和终止阈值之间的间隔

distributed.worker.http.routes ['distributed.http.worker.prometheus', 'distributed.http.health', 'distributed.http.statics'] ¶: 一个可以根据需要包含或排除的模块列表，如 "prometheus" 和 "health"。这些模块将具有一个 ``routes`` 关键字，该关键字被添加到主要的 HTTP 服务器。这是一个可以扩展用户定义模块的列表。

分布式 Nanny ¶

distributed.nanny.preload [] ¶: 在 nanny 生命周期内运行自定义模块。您可以在 nanny 启动和关闭时运行自定义模块。有关更多信息，请参阅 https://docs.dask.org.cn/en/latest/how-to/customize-initialization.html

distributed.nanny.preload-argv [] ¶: 传递给上述 preload 脚本的参数。有关更多信息，请参阅 https://docs.dask.org.cn/en/latest/how-to/customize-initialization.html

distributed.nanny.pre-spawn-environ.MALLOC_TRIM_THRESHOLD_ 65536 ¶: 无注释

distributed.nanny.pre-spawn-environ.OMP_NUM_THREADS 1 ¶: 无注释

distributed.nanny.pre-spawn-environ.MKL_NUM_THREADS 1 ¶: 无注释

distributed.nanny.pre-spawn-environ.OPENBLAS_NUM_THREADS 1 ¶: 无注释

分布式管理 ¶

distributed.admin.large-graph-warning-threshold 10MB ¶: 提交的大任务图何时引发警告的字节阈值。默认为 10MB。

distributed.admin.tick.interval 20ms ¶: tick 之间的时间，默认为 20ms

distributed.admin.tick.limit 3s ¶: 触发警告之前允许的时间

distributed.admin.tick.cycle 1s ¶: 验证事件循环速度之间的时间

distributed.admin.max-error-length 10000 ¶: 追溯文本的最大长度。一些 Python tracebacks 会非常长（尤其是在堆栈溢出错误中）。如果 traceback 的大小（以字节为单位）大于此值，则会将其截断。

distributed.admin.log-length 10000 ¶: worker/scheduler 日志在内存中保留的最大长度。可以通过 get_scheduler_logs() / get_worker_logs() 获取。设置为 null 表示无限制。

distributed.admin.log-format %(asctime)s - %(name)s - %(levelname)s - %(message)s ¶: 要发出的日志格式。请参阅 https://docs.pythonlang.cn/3/library/logging.html#logrecord-attributes

distributed.admin.low-level-log-length 1000 ¶: 供开发人员查看的各种事件日志的最大长度。设置为 null 表示无限制。

distributed.admin.pdb-on-err False ¶: 调度错误时进入 Python Debugger

distributed.admin.system-monitor.interval 500ms ¶: 查询 cpu/内存统计信息的轮询时间，默认为 500ms

distributed.admin.system-monitor.log-length 7200 ¶: 内存中保留的最大样本数。乘以 `interval` 可获得日志持续时间。设置为 null 表示无限制。

distributed.admin.system-monitor.disk True ¶: 是否应包含磁盘指标？（它们可能在某些系统中导致问题）

distributed.admin.system-monitor.host-cpu False ¶: 是否应包含主机范围的 CPU 使用情况，以及非常详细的细分？

distributed.admin.system-monitor.gil.enabled True ¶: 启用 GIL 争用监控

distributed.admin.system-monitor.gil.interval 1ms ¶: GIL 轮询间隔。更频繁的轮询会反映更准确的 GIL 争用指标，但也更有可能影响运行时性能。

distributed.admin.event-loop tornado ¶: 要使用的事件循环，必须是 tornado、asyncio 或 uvloop 之一。

分布式 RMM ¶

distributed.rmm.pool-size None ¶: 内存池的大小（以字节为单位）。

变更日志

操作指南…