从background_pool_size参数，看clickhouse启动流程之load table分析

image.png

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, public MergeTreeData {
...
private:
  /// Task handler for merges, mutations and moves.
    BackgroundProcessingPool::TaskHandle merging_mutating_task_handle;
    BackgroundProcessingPool::TaskHandle moving_task_handle;

    std::vector 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服务。

chtest.png

由上序列图分析，可以看到，ch后台merge job的调度，依赖于一个global的pool context，这个pool的大小，是tables级别的。

至于我们的老朋友Too many parts 这个错误，和我们的线程设置大小虽然有点关系，但更多时候并不是直接原因，这里ch的架构师alexy也给出了解释：
https://github.com/ClickHouse/ClickHouse/issues/11193

image.png

写在最后：

ch大量应用了c++的新特性，一个不小心就掉到c++的语法糖中一发而不可收拾，越来越像python的写法看似随心所欲，其背后是ch团队对于操作系统、机器特性的深入理解。