min_chunk_bytes_for_parallel_parsing
- Тип: беззнаковое целое число
- Значение по умолчанию: 1 MiB
min_compress_block_size
min_compress_block_size. По умолчанию — 65 536.
Если объем несжатых данных меньше max_compress_block_size, фактический размер блока будет не меньше этого значения и не меньше объема данных для одной метки.
Рассмотрим пример. Предположим, что при создании таблицы для index_granularity было задано значение 8192.
Записывается столбец типа UInt32 (4 байта на значение). При записи 8192 строк общий объем составит 32 КБ данных. Поскольку min_compress_block_size = 65,536, сжатый блок будет формироваться на каждые две метки.
Записывается столбец URL типа String (средний размер — 60 байт на значение). При записи 8192 строк средний объем будет чуть меньше 500 КБ данных. Поскольку это больше 65,536, сжатый блок будет формироваться для каждой метки. В этом случае при чтении с диска данных в диапазоне одной метки лишние данные распаковываться не будут.
Это настройка экспертного уровня, и не стоит изменять ее, если вы только начинаете работать с ClickHouse.
min_filtered_ratio_for_lazy_final
min_hit_rate_to_use_consecutive_keys_optimization
min_os_cpu_wait_time_ratio_to_throw
min_outstreams_per_resize_after_split
Resize или StrictResize после разделения, выполняемого при генерации конвейера. Если итоговое количество потоков меньше этого значения, операция разделения не выполняется.
Что такое узел Resize
Resize — это процессор в конвейере выполнения запроса, который регулирует количество потоков данных, проходящих через конвейер. Он может как увеличивать, так и уменьшать число потоков, чтобы сбалансировать рабочую нагрузку между несколькими потоками выполнения или процессорами. Например, если для запроса требуется больший параллелизм, узел Resize может разделить один поток на несколько. И наоборот, он может объединить несколько потоков в меньшее число, чтобы объединить обработку данных.
Узел Resize обеспечивает равномерное распределение данных между потоками, сохраняя структуру блоков данных. Это помогает эффективнее использовать ресурсы и повышает производительность запросов.
Почему узел Resize нужно разделить
Resize возникает сильное contention, особенно в средах с большим числом ядер, и это приводит к следующему:
- Увеличивается latency для ExecutingGraph::updateNode, что напрямую влияет на query performance.
- Избыточные циклы CPU впустую расходуются на contention в spin-lock (
native_queued_spin_lock_slowpath), что снижает эффективность. - Снижается utilization CPU, что ограничивает параллелизм и throughput.
Как разделяется узел Resize
- Проверяется число выходных потоков, чтобы убедиться, что разделение можно выполнить: число выходных потоков у каждого процессора после разделения достигает порога
min_outstreams_per_resize_after_splitили превышает его. - Узел
Resizeделится на более мелкие узлыResizeс одинаковым количеством портов, каждый из которых обрабатывает подмножество входных и выходных потоков. - Каждая группа обрабатывается независимо, что снижает конкуренцию за блокировки.
Разделение узла Resize с произвольным числом входов и выходов
Resize после разделения, часть входов подключается к NullSource, а часть выходов — к NullSink. Это позволяет выполнить разделение, не влияя на общий поток данных.
Назначение настройки
min_outstreams_per_resize_after_split гарантирует, что разделение узлов Resize оправдано и не приводит к созданию слишком малого числа потоков, что может снизить эффективность параллельной обработки. Задавая минимальное количество выходных потоков, эта настройка помогает поддерживать баланс между параллелизмом и накладными расходами, оптимизируя выполнение запроса в сценариях, связанных с разделением и слиянием потоков.
Отключение настройки
Resize, установите для этой настройки значение 0. Это предотвратит split узлов Resize при генерации конвейера, и они сохранят исходную структуру без разделения на более мелкие узлы.