线程池 | ElasticSearch 7.7 权威指南中文版

原英文版地址: https://www.elastic.co/guide/en/elasticsearch/reference/7.7/modules-threadpool.html, 原文档版权归 www.elastic.co 所有
本地英文版地址: ../en/modules-threadpool.html

重要: 此版本不会发布额外的bug修复或文档更新。最新信息请参考当前版本文档。

» » »

« 传输预警设置 »

线程池 (thread pools)

一个节点使用若干个线程池来管理内存消耗。与许多线程池关联的队列允许保留挂起的请求，而不是丢弃。

有若干个线程池，但重要的几个是：

generic: 对应一般操作(例如，后台节点发现)。其线程池类型为 scaling

search: 对应 count、search、suggest 操作。其线程池类型为 fixed_auto_queue_size(自动的固定的队列大小)，大小为 int((可用的处理器数 * 3) / 2) + 1，初始队列大小为 1000
search_throttled: 对应 搜索节流索引(search_throttled indices) 上的 count、search、suggest、get 操作。其线程池类型为 fixed_auto_queue_size(自动的固定的队列大小)，大小为1，初始队列大小为 100
get: 对应 get 操作。其线程池类型为 fixed(固定的)，大小为 可用的处理器数，队列大小为 1000
analyze: 对应分析(analyze) 请求。其线程池类型为 fixed(固定的)，大小为 1，队列大小为 16
write: 对应单个文档的 index/delete/update 及批量(bulk) 请求。其线程池类型为 fixed(固定的)，大小为 可用的处理器数, 队列大小为 200。线程池最大数量为 1 + 可用的处理器数。
snapshot: 对应 snapshot/restore 操作。其线程池类型为 scaling(可扩展的)，保持活动状态 5m，最大值为 min(5, (可用的处理器数)/2)。
warmer: 对应段(segment)的预热(warm-up) 操作。其线程池类型为 scaling(可扩展的)，保持活动状态 5m，最大值为 min(5, (可用的处理器数)/2)。
refresh: 对应刷新(refhresh) 操作。其线程池类型为 scaling(可扩展的)，保持活动状态 5m，最大值为 min(10, (可用的处理器数)/2)。
listener: 主要用于java客户端在监听器线程设置为true时执行操作。其线程池类型为 scaling(可扩展的)，默认最大值为 min(10, (可用的处理器数)/2)。
fetch_shard_started: 对应列出分片状态。其线程池类型为 scaling(可扩展的)，保持活动状态 5m，默认最大值为 2 * 可用的处理器数。
fetch_shard_store: 对应列出分片存储。其线程池类型为 scaling(可扩展的)，保持活动状态 5m，默认最大值为 2 * 可用的处理器数。
flush: 对应 flush(冲洗)、synced flush(同步冲洗) 及 translog(事务日志) fsync 操作。其线程池类型为 scaling(可扩展的)，保持活动状态 5m，默认最大值为 min(5, 可用的处理器数/2)。
force_merge: 对应强制合并(force merge) 操作。其线程池类型为 fixed(固定的)，大小为 1，队列大小无限制。
management: 对应集群管理。其线程池类型为 scaling(可扩展的)，保持活动状态 5m，默认最大值为 5。

可以通过设置特定类型的参数来更改特定的线程池；例如，更改write线程池中的线程数量：

thread_pool:
    write:
        size: 30

线程池类型

以下是线程池的类型及其各自的参数：

`fixed`

fixed类型的线程池拥有一个固定大小的线程来处理带有队列(可选有界)的请求，用于处理没有线程为其服务的等待请求。

参数 size 控制线程的数量。

参数 queue_size 允许控制没有线程执行请求的队列大小。默认情况下，它被设置为-1，这意味着它是无限制的。当队列已满时，进来的请求将被终止。

thread_pool:
    write:
        size: 30
        queue_size: 1000

`fixed_auto_queue_size`

这个功能是实验性的，可能会在未来的版本中完全更改或删除。 Elastic 将尽最大努力修复任何问题，但实验性功能不受官方 GA 特性的 SLA 支持。

废弃的 [实验性的fixed_auto_queue_size 线程池类型已在 7.7.0 版本废弃，并将在 8.0 版本中移除]

fixed_auto_queue_size 类型的线程池持有一个固定大小的线程来处理带有一个有界队列的请求，该队列用于处理没有线程为其服务的等待请求。它类似于fixed 线程池，然而，queue_size 根据 Little’s Law的计算自动调整。每当 auto_queue_frame_size 操作完成时，这些计算将潜在地将 auto_queue_frame_size 上下调整50。

参数 size 控制线程的数量。

参数 queue_size允许控制没有线程执行的挂起请求队列的初始大小。

min_queue_size设置控制queue_size可调整的最小数量。

min_queue_size设置控制queue_size可调整的最大数量。

auto_queue_frame_size设置控制在队列调整之前进行测量的操作次数。它应该足够大，使得单个操作不会过度地影响计算。

target_response_time 是一个时间值设置，指示线程池队列中任务的目标平均响应时间。如果任务经常超过这个时间，线程池队列数将被减小，以便拒绝任务。

thread_pool:
    search:
        size: 30
        queue_size: 500
        min_queue_size: 10
        max_queue_size: 1000
        auto_queue_frame_size: 2000
        target_response_time: 1s

`scaling`

scaling 类型的线程池持有一个动态数量的线程。这个数字与工作负载成正比，并且在core和max参数的值之间变化。

参数 keep_alive 决定了一个线程在不做任何工作的情况下应该在线程池中保留多长时间。

thread_pool:
    warmer:
        core: 1
        max: 8
        keep_alive: 2m

分配的处理器设置 (Allocated processors setting)

处理器的数量是自动检测的，线程池设置是基于它自动设置的。在某些情况下，覆盖检测到的处理器数量会很有用。这可以通过显式设置 node.processors 设置来实现。

node.processors: 2

有几个显式覆盖 node.processors 设置的用例：

如果你在同一主机上运行多个 Elasticsearch 实例，但希望 Elasticsearch 调整线程池的大小，就像它只有一部分 CPU 一样，那么应该所需的部分的值来覆盖 node.processors 设置，例如，如果你在一个 16 核的机器上运行两个 Elasticsearch 实例，设置 node.processors 为 8 。请注意，这是一个专家级的用例，涉及的内容远不止配置 node.processors 设置，因为还有其他考虑事项，如更改垃圾回收器线程的数量、将进程锁定到内核等等。
有时检测到的处理器数量是错误的，在这种情况下，显式设置 node.processors 设置可以解决此类问题。

为了检查检测到的处理器数量，使用带有 os 标志的节点信息 API。

« 传输预警设置 »