google翻译一下：
设置在表引擎中执行后台操作的线程数（例如，在MergeTree引擎表中的合并）。此设置是从ClickHouse服务器启动时的默认配置文件中应用的，无法在用户会话中进行更改。通过调整此设置，可以管理CPU和磁盘负载。较小的池使用较少的CPU和磁盘资源，但是后台进程的执行速度较慢，这最终可能会影响查询性能。
更改它之前，还请查看相关的MergeTree设置，例如number_of_free_entries_in_pool_to_lower_max_size_of_merge和number_of_free_entries_in_pool_to_execute_mutation。
从描述上看，这个值是针对所有表的一个限制。实际工程实践中这个值的控制粒度是什么样子的？我们PS -T 查看线上一个ch服务：
161 AsyncBlockInput
1 AsyncMetrics
32 BackgrProcPool
16 BgDistSchPool
1 BgDistSchPool/D
16 BgSchPool
1 BgSchPool/D
9 clickhouse-serv
1 CMD
2 ConfigReloader
2 ExterLdrReload
4 HTTPHandler
86 QueryPipelineEx
1 SessionCleaner
1 SystemLogFlush
14 TCPHandler
发现这个叫BackgrProcPool的线程数和线上设置值匹配，于是代码入手看看这个参数是如何控制后台merge线程数的。
首先，代码中找到可能设置"BackgrProcPool"名字的类。
BackgroundProcessingPool(int size_,
const PoolSettings & pool_settings = {},
const char * log_name = "BackgroundProcessingPool",
const char * thread_name_ = "BackgrProcPool");
BackgroundProcessingPool::BackgroundProcessingPool(int size_,
const PoolSettings & pool_settings,
const char * log_name,
const char * thread_name_)
: size(size_)
, thread_name(thread_name_)
, settings(pool_settings)
{
logger = &Logger::get(log_name);
LOG_INFO(logger, "Create " << log_name << " with " << size << " threads");
threads.resize(size);
for (auto & thread : threads)
thread = ThreadFromGlobalPool([this] { threadFunction(); });
}
对于每个表，原来clickhouse都会通过一个global的线程池来调度这些任务：
//github.com/ClickHouse/src/Storages/StorageMergeTree.h
class StorageMergeTree : public ext::shared_ptr_helper<StorageMergeTree>, public MergeTreeData {
...
private:
/// Task handler for merges, mutations and moves.
BackgroundProcessingPool::TaskHandle merging_mutating_task_handle;
BackgroundProcessingPool::TaskHandle moving_task_handle;
std::vector<MergeTreeData::AlterDataPartTransactionPtr> prepareAlterTransactions(
const ColumnsDescription & new_columns, const IndicesDescription & new_indices, const Context & context);
void loadMutations();
...
}
//github.com/ClickHouse/src/Storages/StorageMergeTree.cpp
void StorageMergeTree::startup()
{
clearOldPartsFromFilesystem();
/// Temporary directories contain incomplete results of merges (after forced restart)
/// and don't allow to reinitialize them, so delete each of them immediately
clearOldTemporaryDirectories(0);
/// NOTE background task will also do the above cleanups periodically.
time_after_previous_cleanup.restart();
if (!getSettings()->disable_background_merges)
merging_mutating_task_handle = global_context.getBackgroundPool().addTask([this] { return mergeMutateTask(); });
if (areBackgroundMovesNeeded())
moving_task_handle = global_context.getBackgroundMovePool().addTask([this] { return movePartsTask(); });
}
//github.com/ClickHouse/src/Interpreters/Context.cpp
BackgroundProcessingPool & Context::getBackgroundPool()
{
auto lock = getLock();
if (!shared->background_pool)
shared->background_pool.emplace(settings.background_pool_size);
return *shared->background_pool;
}
//github.com/ClickHouse/src/Core/Settings.h
M(SettingUInt64, background_pool_size, 16, "Number of threads performing background work for tables (for example, merging in merge tree). Only has meaning at server startup.", 0) \
上述代码分析基于20.3.15版本，下面的分析基于代码20.12.5版本。
20.12.5版本优化了后台任务子模块的实现：
https://github.com/ClickHouse/ClickHouse/pull/15983
clickhouse启动的时候，会load所有的表，把表按引擎级别在后台启动merge服务。
由上序列图分析，可以看到，ch后台merge job的调度，依赖于一个global的pool context，这个pool的大小，是tables级别的。
至于我们的老朋友Too many parts 这个错误，和我们的线程设置大小虽然有点关系，但更多时候并不是直接原因，这里ch的架构师alexy也给出了解释：
https://github.com/ClickHouse/ClickHouse/issues/11193
写在最后：
ch大量应用了c++的新特性，一个不小心就掉到c++的语法糖中一发而不可收拾，越来越像python的写法看似随心所欲，其背后是ch团队对于操作系统、机器特性的深入理解。
