配置

配置¶

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

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

YAML 文件位于 ~/.config/dask/ 或 /etc/dask/ 中
环境变量，例如 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 解析所有值，允许用户传递数字和布尔值（如上例中的 True）以及列表、字典等，使用正常的 Python 语法。

环境变量优先于 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）尤其如此。

直接从命令行界面¶

配置也可以通过命令行界面设置和查看。

$ 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/stable/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]¶

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

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

参数

config字典、可迭代对象或字符串: 用于搜索环境变量的输入对象

返回

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 将报错，而不是回退到 uuid。默认为 ``false``。

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

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

dataframe.shuffle.compression None ¶: 用于磁盘 shuffle 的压缩算法。用于压缩的库 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 ¶: 用于 rechunking（重分块）的方法。可能的值有 tasks 或 p2p。如果为 null，则根据应用选择最佳方法。

array.rechunk.threshold 4 ¶: 基于任务的 shuffle 引入中间步骤时的图增长因子阈值。

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

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

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

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

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

optimization.fuse.ave-width 1 ¶: 宽度的上限，其中 width = 节点数 / 高度，这是衡量并行性的一个良好指标。

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` 重命名融合的键。重命名融合的键可以使图更容易理解和 comprehendible，但这会带来额外的处理成本。如果为 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 回溯信息以提高可读性。删除所有与列出的正则表达式之一匹配的模块。始终保留第一帧和最后一帧。

分布式客户端 ¶

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

分布式通信 ¶

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

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

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

distributed.comm.compression False ¶: 要使用的压缩算法。“auto”在安装了 lz4 时默认为 lz4，否则在安装了 snappy 时默认为 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 ¶: 在 worker 之间 shuffle 数据时，单个 worker 套接字上可能会出现 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 能够正确识别 GPU 与专用网络硬件（如 InfiniBand）的连接性是必需的。这允许 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 ¶: 仪表盘链接的格式。这用于打印仪表盘链接的任何地方。它会填充相关信息，例如 scheme、主机和端口号。

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 ¶: 任意一对 worker 之间的预期带宽。这用于进行调度决策。调度器将使用此值作为基线，但也会随着时间学习它。

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

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

distributed.scheduler.default-data-size 1kiB ¶: 如果我们对数据块一无所知，则其默认大小。这由调度器用于某些调度决策。

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

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

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

distributed.scheduler.work-stealing True ¶: 是否动态地在 worker 之间平衡工作。有时一个 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 饱和度时，控制何时将特定任务组识别为 rootish。如果任务组只有一定数量的依赖项（默认为 5），则将其标识为 rootish。对于非常大的数据集（其中来自 xarray 的数据任务数量可能高于 5），这可能会出错。增加此限制将成功捕获这些根任务，但会增加将任务组错误识别为 rootish 的风险，这可能会影响性能。

distributed.scheduler.rootish-taskgroup-dependencies 5 ¶: 控制任务组要被视为 rootish 所能拥有的传递依赖项数量。它检查 rootish 任务组的每个依赖项的依赖项数量。与 ``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 ¶: 调度器验证所有已获取租约是否过期的间隔。此间隔必须始终小于租约超时本身。

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 [] ¶: 要排除的处理程序列表。调度器通过接收来自各种 worker 和客户端的消息，然后根据这些消息执行操作。每条消息都有一个操作，例如“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 ¶: 创建 worker 时是否使用锁文件。Worker 会创建一个本地目录来存放临时文件。当在同一进程上同时创建许多 worker 时，这些 worker 可能会因为同时尝试创建此目录而相互冲突。为了避免这种情况，Dask 通常使用基于文件的锁。但是，在某些系统上，基于文件的锁不起作用。这在 HPC NFS 系统上尤其常见，用户可能希望将其设置为 false。

distributed.worker.transfer.message-bytes-limit 50MB ¶: worker 在单个 gather 操作中向另一个 worker 请求的最大数据量（字节）。任务会批量 gather，如果批量中的第一个任务大于此值，该任务仍将被 gather 以确保进度。因此，此限制不是绝对的。请注意，此限制适用于单个 gather 操作，并且 worker 可以并行地从多个 worker 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 小时”。

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

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

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

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 ¶: 用于衡量 worker 内存使用情况的 distributed.scheduler.MemoryState 的属性之一。

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

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

distributed.worker.memory.rebalance.sender-recipient-gap 0.1 ¶: worker 进程内存占集群平均内存的比例，在此比例范围内，worker 在 rebalance 操作期间既不是数据的发送者也不是接收者。例如，如果集群平均占用率为 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 时默认为 lz4，否则在安装了 snappy 时默认为 snappy，否则为 false。zlib 和 zstd 仅在此处明确请求时使用。无论此设置如何，不可压缩数据始终不压缩。另请参阅 distributed.comm.compression。

distributed.worker.memory.monitor-interval 100ms ¶: 检查 spill、pause 和 terminate 阈值之间的间隔。

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 回溯信息可能非常非常长（尤其是在栈溢出错误中）。如果回溯信息大于此大小（以字节为单位），则将其截断。

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 ¶: 内存池的大小（字节）。

更新日志

如何操作…