настройки сервера concurrent_threads_*

Эти настройки задают конфигурацию сервера ClickHouse и автоматически генерируются из исходного кода ClickHouse.

Управляет тем, как слот CPU выделяются запросам.

Когда true (по умолчанию), запрос запускается с одним слотом CPU и запрашивает дополнительные слоты у планировщика только тогда, когда его конвейер действительно передаёт больше работы, которую можно распараллелить. Это позволяет избежать ситуации, когда запрос резервирует до max_threads слотов, но фактически использует лишь часть из них, не оставляя ресурсов другим параллельным запросам. Применяется как к управлению параллелизмом, так и к вытесняющему планировщику CPU для рабочих нагрузок.

Когда false, запрос при запуске сразу запрашивает все слоты max_threads.

Политика, определяющая, как планируются слоты CPU, заданные параметрами concurrent_threads_soft_limit_num и concurrent_threads_soft_limit_ratio_to_cores. Алгоритм, управляющий распределением ограниченного числа слотов CPU между параллельными запросами. Планировщик можно изменить во время выполнения без перезапуска сервера.

Возможные значения:

• round_robin — Каждый запрос с настройкой use_concurrency_control = 1 выделяет до max_threads слотов CPU. Один слот на поток. При конкуренции за ресурсы слоты CPU выдаются запросам по алгоритму round-robin. Обратите внимание, что первый слот выдаётся безусловно, что может приводить к несправедливому распределению и увеличению задержки для запросов с большим max_threads при наличии большого числа запросов с max_threads = 1.
• fair_round_robin — Каждый запрос с настройкой use_concurrency_control = 1 выделяет до max_threads - 1 слотов CPU. Это вариант round_robin, в котором для первого потока каждого запроса слот CPU не требуется. Таким образом, запросы с max_threads = 1 не требуют слотов и не могут несправедливо занять все слоты. Слоты не выдаются безусловно.
• max_min_fair — Каждый запрос с настройкой use_concurrency_control = 1 выделяет до max_threads - 1 слотов CPU. Похож на fair_round_robin, но освобождённые слоты всегда выдаются запросу с минимальным числом уже выделенных слотов. Это обеспечивает более справедливое распределение при высокой сверхподписке, когда множество запросов конкурируют за ограниченное число слотов CPU. Короткие запросы не оказываются в невыгодном положении из-за долгих запросов, которые со временем накопили больше слотов.

Максимальное число потоков обработки запросов, не включая потоки, используемые для получения данных с удалённых серверов, которое может быть задействовано для выполнения всех запросов. Это не жёсткое ограничение. Если лимит достигнут, запросу всё равно будет выделен как минимум один поток. Во время выполнения запрос может увеличить число потоков до требуемого, если появятся дополнительные доступные потоки.