Skip to main content
これらの設定は system.settings で確認でき、ソースコード から自動生成されています。

min_chunk_bytes_for_parallel_parsing

  • 型: 符号なし整数
  • デフォルト値: 1 MiB
各スレッドが並列にパースする chunk の最小サイズを、バイト単位で指定します。

min_compress_block_size

MergeTree テーブルで使用されます。クエリ処理時のレイテンシを抑えるため、サイズが min_compress_block_size 以上の block は、次の mark の書き込み時に圧縮されます。デフォルト値は 65,536 です。 非圧縮データが max_compress_block_size 未満の場合、実際の block サイズはこの値以上であり、かつ 1 つの mark 分のデータ量以上になります。 例を見てみましょう。テーブル作成時に index_granularity が 8192 に設定されているとします。 UInt32 型のカラム (値 1 つあたり 4 バイト) を書き込む場合、8192 行を書き込むと合計 32 KB のデータになります。min_compress_block_size = 65,536 であるため、圧縮 block は 2 つの mark ごとに作成されます。 String 型の URL カラム (値 1 つあたりの平均サイズが 60 バイト) を書き込む場合、8192 行を書き込むと平均で 500 KB 弱のデータになります。これは 65,536 を超えるため、圧縮 block は mark ごとに作成されます。この場合、ディスクから 1 つの mark の範囲のデータを読み取る際に、余分なデータが展開されることはありません。
これは上級者向けの設定です。ClickHouse を使い始めたばかりであれば、変更しないでください。

min_filtered_ratio_for_lazy_final

遅延実行 FINAL 最適化において、索引解析によってフィルタリングされる marks の最小比率です。フィルタリングされる marks の割合がこの値を下回る場合は、通常の FINAL にフォールバックします。値 0 を指定すると、このチェックは無効になります。

min_hit_rate_to_use_consecutive_keys_optimization

集約における連続キー最適化で使用されるcacheを有効なままにするための最小ヒット率

min_os_cpu_wait_time_ratio_to_throw

クエリを拒否対象とみなすための、OS の CPU 待機時間 (OSCPUWaitMicroseconds Metric) とビジー時間 (OSCPUVirtualTimeMicroseconds Metric) の最小比率です。確率は最小比率と最大比率の間で線形補間して計算され、この時点での確率は 0 です。

min_outstreams_per_resize_after_split

パイプライン生成時に分割が実行された後の、Resize または StrictResize プロセッサの出力ストリーム数の最小値を指定します。結果のストリーム数がこの値未満の場合、分割操作は実行されません。

Resize ノードとは

Resize ノードは、クエリパイプライン内を流れるデータストリーム数を調整するプロセッサです。複数のスレッドやプロセッサ間でワークロードのバランスを取るために、ストリーム数を増減できます。たとえば、クエリでより高い並列度が必要な場合、Resize ノードは単一ストリームを複数のストリームに分割できます。逆に、複数のストリームをより少ない数のストリームにマージして、データ処理を集約することもできます。 Resize ノードは、データブロックの構造を維持したまま、データが各ストリームに均等に分配されるようにします。これにより、リソース使用状況を最適化し、クエリパフォーマンスを向上させることができます。

Resize ノードを分割する必要がある理由

パイプラインの実行中、中央ハブとなる Resize ノードの ExecutingGraph::Node::status_mutex では、特にコア数の多い環境で深刻な contention が発生し、この contention によって次のような問題が生じます。
  1. ExecutingGraph::updateNode のレイテンシが増加し、クエリパフォーマンスに直接影響します。
  2. スピンロックの contention (native_queued_spin_lock_slowpath) によって過剰な CPU サイクルが浪費され、効率が低下します。
  3. CPU 使用率が低下し、並列度とスループットが制限されます。

Resize ノードの分割方法

  1. まず出力ストリーム数を確認し、分割を実行可能かどうかを判定します。各分割 プロセッサ の出力ストリーム数は、min_outstreams_per_resize_after_split のしきい値以上である必要があります。
  2. Resize ノードは、同じ数のポートを持つ複数の小さな Resize ノードに分割され、それぞれが入力ストリームと出力ストリームの一部を処理します。
  3. 各グループは独立して処理されるため、ロック競合が軽減されます。

任意の入力/出力を持つ Resize ノードの分割

入力/出力の数が分割された Resize ノードの数で割り切れない場合、一部の入力は NullSource に、一部の出力は NullSink に接続されます。これにより、全体のデータフローに影響を与えることなく分割できます。

設定の目的

min_outstreams_per_resize_after_split 設定は、Resize ノードの分割が適切に機能するようにし、ストリーム数が少なすぎて並列処理の効率が低下するのを防ぎます。出力ストリームの最小数を確保することで、ストリームの分割やマージを伴うシナリオでも並列度とオーバーヘッドのバランスを維持し、クエリ実行を最適化します。

設定を無効にする

Resize ノードの分割を無効にするには、この設定を 0 に設定します。これにより、パイプライン生成時に Resize ノードが分割されなくなり、より小さなノードに分けられることなく、元の構造を維持できます。

min_table_rows_to_use_projection_index

テーブルから読み取ると推定される行数がこのしきい値以上の場合、ClickHouse はクエリ実行時にプロジェクション索引の使用を試みます。
最終更新日 2026年7月23日