スレッドプール

ノードは、メモリ消費を管理するためにいくつかのスレッドプールを使用します。多くのスレッドプールに関連付けられたキューは、保留中のリクエストを破棄するのではなく保持することを可能にします。

いくつかのスレッドプールがありますが、重要なものには次のものが含まれます：

  • generic

  • 一般的な操作用（例えば、バックグラウンドノード発見）。スレッドプールのタイプは scaling です。

  • search
  • シャードレベルでのカウント/検索操作の調整用で、計算は search_worker スレッドプールにオフロードされます。fetch やその他の検索関連操作でも使用されます。スレッドプールのタイプは fixed で、サイズは int((# of allocated processors* 3) / 2) + 1、キューサイズは 1000 です。
  • search_worker
  • 同じシャード内のセグメント間で可能な限り同時に実行されるカウント/検索操作の重い負荷用。スレッドプールのタイプは fixed で、サイズは int((# of allocated processors* 3) / 2) + 1、キューサイズは無制限です。
  • search_throttled
  • search_throttled indices に対するカウント/検索/提案/取得操作用。スレッドプールのタイプは fixed で、サイズは 1、キューサイズは 100 です。
  • search_coordination
  • 軽量の検索関連調整操作用。スレッドプールのタイプは fixed で、サイズは (# of allocated processors) / 2、キューサイズは 1000 です。
  • get
  • 取得操作用。スレッドプールのタイプは fixed で、サイズは int((# of allocated processors* 3) / 2) + 1、キューサイズは 1000 です。
  • analyze
  • 分析リクエスト用。スレッドプールのタイプは fixed で、サイズは 1、キューサイズは 16 です。
  • write
  • 単一ドキュメントのインデックス/削除/更新、インジェストプロセッサ、およびバルクリクエスト用。スレッドプールのタイプは fixed で、サイズは # of allocated processors、キューサイズは 10000 です。このプールの最大サイズは 1 +# of allocated processors です。
  • snapshot
  • スナップショット/復元操作用。スレッドプールのタイプは scaling で、キープアライブは 5m です。750MB以上のヒープを持つノードでは、このプールの最大サイズはデフォルトで 10 です。750MB未満のヒープを持つノードでは、このプールの最大サイズはデフォルトで min(5, (# of allocated processors) / 2) です。
  • snapshot_meta
  • スナップショットリポジトリメタデータの読み取り操作用。スレッドプールのタイプは scaling で、キープアライブは 5m で、最大は min(50, (# of allocated processors* 3)) です。
  • warmer
  • セグメントのウォームアップ操作用。スレッドプールのタイプは scaling で、キープアライブは 5m で、最大は min(5, (# of allocated processors) / 2) です。
  • refresh
  • リフレッシュ操作用。スレッドプールのタイプは scaling で、キープアライブは 5m で、最大は min(10, (# of allocated processors) / 2) です。
  • fetch_shard_started
  • シャード状態のリスト表示用。スレッドプールのタイプは scaling で、キープアライブは 5m で、デフォルトの最大サイズは 2 *# of allocated processors です。
  • fetch_shard_store
  • シャードストアのリスト表示用。スレッドプールのタイプは scaling で、キープアライブは 5m で、デフォルトの最大サイズは 2 *# of allocated processors です。
  • flush
  • フラッシュ および トランスログ fsync 操作用。スレッドプールのタイプは scaling で、キープアライブは 5m で、デフォルトの最大サイズは min(5, (# of allocated processors) / 2) です。
  • force_merge
  • 強制マージ 操作用。スレッドプールのタイプは fixed で、サイズは max(1, (# of allocated processors) / 8)、キューサイズは無制限です。
  • management
  • クラスタ管理用。スレッドプールのタイプは scaling で、キープアライブは 5m で、デフォルトの最大サイズは 5 です。
  • system_read
  • システムインデックスに対する読み取り操作用。スレッドプールのタイプは fixed で、デフォルトの最大サイズは min(5, (# of allocated processors) / 2) です。
  • system_write
  • システムインデックスに対する書き込み操作用。スレッドプールのタイプは fixed で、デフォルトの最大サイズは min(5, (# of allocated processors) / 2) です。
  • system_critical_read
  • システムインデックスに対する重要な読み取り操作用。スレッドプールのタイプは fixed で、デフォルトの最大サイズは min(5, (# of allocated processors) / 2) です。
  • system_critical_write
  • システムインデックスに対する重要な書き込み操作用。スレッドプールのタイプは fixed で、デフォルトの最大サイズは min(5, (# of allocated processors) / 2) です。
  • watcher
  • ウォッチ実行 用。スレッドプールのタイプは fixed で、デフォルトの最大サイズは min(5 * (# of allocated processors), 50)、キューサイズは 1000 です。
  • esql_worker
  • ES|QL 操作を実行します。スレッドプールのタイプは fixed で、サイズは int((# of allocated processors * 3) / 2) + 1、キューサイズは 1000 です。

スレッドプールの設定は 静的 であり、elasticsearch.yml を編集することで変更できます。特定のスレッドプールを変更するには、そのタイプ固有のパラメータを設定します。例えば、write スレッドプールのスレッド数を変更することができます：

Yaml

  1. thread_pool:
  2.    write:
  3.    size: 30

スレッドプールのタイプ

以下はスレッドプールのタイプとそれぞれのパラメータです：

固定

fixed スレッドプールは、リクエストを処理するために固定サイズのスレッドを保持し、サービスするスレッドがない保留中のリクエストのためのキュー（オプションで制限付き）を持ちます。

size パラメータは、スレッドの数を制御します。

queue_size は、実行するスレッドがない保留中のリクエストのキューのサイズを制御します。デフォルトでは、-1 に設定されており、これは無制限を意味します。リクエストが来てキューが満杯になると、リクエストは中止されます。

Yaml

  1. thread_pool:
  2.    write:
  3.    size: 30
  4.    queue_size: 1000

スケーリング

scaling スレッドプールは、動的な数のスレッドを保持します。この数は、作業負荷に比例し、core と max パラメータの値の間で変動します。

keep_alive パラメータは、スレッドプール内でスレッドが作業をせずにどれくらいの間保持されるべきかを決定します。

Yaml

  1. thread_pool:
  2.    warmer:
  3.    core: 1
  4.    max: 8
  5.    keep_alive: 2m

割り当てられたプロセッサ設定

プロセッサの数は自動的に検出され、スレッドプールの設定はそれに基づいて自動的に設定されます。場合によっては、検出されたプロセッサの数を上書きすることが有用です。これは、node.processors 設定を明示的に設定することで行えます。この設定は、利用可能なプロセッサの数によって制限され、浮動小数点数を受け入れます。これは、Elasticsearch ノードが CPU 制限で実行されるように構成されている環境（例えば、Cgroups の下での CPU シェアやクォータ）で有用です。

Yaml

  1. node.processors: 2

node.processors 設定を明示的に上書きするいくつかのユースケースがあります：

  • 1. 同じホストで複数の Elasticsearch インスタンスを実行しているが、Elasticsearch に CPU の一部しか持っていないかのようにスレッドプールのサイズを設定させたい場合、node.processors 設定を希望の割合に上書きする必要があります。例えば、16コアのマシンで2つの Elasticsearch インスタンスを実行している場合、node.processors を 8 に設定します。これは専門的なユースケースであり、node.processors 設定を設定するだけではなく、ガベージコレクタスレッドの数を変更したり、プロセスをコアに固定したりするなど、他の考慮事項が多く関与しています。
  • 2. 時々、プロセッサの数が誤って検出され、そのような場合には node.processors 設定を明示的に設定することでその問題を回避できます。

検出されたプロセッサの数を確認するには、os フラグを使用してノード情報 API を使用します。