我如何用兩行代碼節(jié)省了30%的CPU

將滴滴技術(shù)設(shè)為“ 星標(biāo)?? ”

第一時間收到文章更新

ClickHouse 是一個開源的用于實時數(shù)據(jù)分析高性能列式分布式數(shù)據(jù)庫， 支持向量化計算引擎、多核并行計算、高壓縮比等，在分析型數(shù)據(jù)庫中單表查詢性能第一。滴滴從2020年開始引進Clickhouse，服務(wù)網(wǎng)約車及日志檢索等核心業(yè)務(wù)，節(jié)點數(shù)300+，每天PB級別的數(shù)據(jù)寫入，每天千萬級別的查詢量，其中最大的集群有200+節(jié)點。本篇文章主要介紹Clickhouse在性能優(yōu)化上的一個點，從發(fā)現(xiàn)問題到最后解決問題的過程，并獲取較好的收益。

01

發(fā)現(xiàn)問題

線上節(jié)點負載比較高，需要定位CPU主要用在什么地方。首先需要確認的是哪個模塊占用了CPU，在Clickhouse中比較耗CPU的主要是查詢、寫入和Merge等模塊。使用top命令定位出占用CPU最高的進程，定位到進程后在使用??top -Hp pid 命令， 查看占用 CPU 最高的線程，如下圖：

1、排在第一是BackgrProcPool線程是負責(zé)執(zhí)行ReplicatedMergeTree表的merge和mutation任務(wù)，需要處理大量的數(shù)據(jù)。

2、排在第二是HTTPHandler線程是負責(zé)處理客戶的http請求，包括查詢解析、優(yōu)化及執(zhí)行計劃的生成等，最終生成的物理執(zhí)行計劃會交由QueryPipelineEx線程來執(zhí)行。

3、接著往下看，會發(fā)現(xiàn)連續(xù)6個BackgrProcPool線程分別占用30%多的CPU，他們主要是負責(zé)磁盤間的數(shù)據(jù)移動，當(dāng)磁盤使用率超過了設(shè)定的閥值（默認是90%），BgMoveProcPool線程就會將該磁盤上的Part文件移動到其他的磁盤，同時如果對表設(shè)置了Move TTL，當(dāng)Part的數(shù)據(jù)過期后就會將該Part移動到目標(biāo)磁盤，主要用來實現(xiàn)數(shù)據(jù)的冷熱分離。BgMoveProc線程池默認最大的線程數(shù)是8，負責(zé)所有MergeTree表磁盤間數(shù)據(jù)的移動。

4、圖中剩下的ZookeeperSend線程和ZookeeperRecv線程分別是負責(zé)發(fā)送對ZK的操作請求及接收對應(yīng)操作的響應(yīng)，ReplicatedMergeTree 表的副本同步機制就依賴ZK來實現(xiàn)的。Clickhouse中還有很多其他的線程，這里就不再一一的介紹。

top 命令持續(xù)監(jiān)聽了一段時間，發(fā)現(xiàn)這8個BgMoveProPool線程的CPU占用幾乎一直是排在前面的，難道有磁盤的使用率已經(jīng)達到90%了，所有的Move線程都在磁盤間搬遷 數(shù)據(jù)？ 但是線上磁盤使用到了80%就會報警，難道報警有問題？

使用?df -h 命令查看了磁盤的使用情況，執(zhí)行后發(fā)現(xiàn)12塊磁盤的使用率都在50%左右，這就很奇怪了，磁盤的空間是充足的且線上的集群也沒有配置冷熱分離，按道理BgMoveProcPool線程就不應(yīng)該占用CPU，究竟在做什么呢？

02

確認問題

為了搞清楚BgMoveProcPool線程到底在執(zhí)行什么，使用pstack pid命令抓取此時的堆棧，多次打印堆棧發(fā)現(xiàn)BgMoveProcPool線程都處于MergeTreePartsMover::selectPartsForMove方法中，堆棧如下：

          
            #0  0x00000000100111a4 in DB::MergeTreePartsMover::selectPartsForMove(std::__1::vector<DB::MergeTreeMoveEntry, std::__1::allocator<DB::MergeTreeMoveEntry> >&, std::__1::function<bool (std::__1::shared_ptr<DB::IMergeTreeDataPart const> const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*)> const&, std::__1::lock_guard<std::__1::mutex> const&) ()
          
          
            #1  0x000000000ff6ef5a in DB::MergeTreeData::selectPartsForMove() ()
          
          
            #2  0x000000000ff86096 in DB::MergeTreeData::selectPartsAndMove() ()
          
          
            #3  0x000000000fe5d102 in std::__1::__function::__func<DB::StorageReplicatedMergeTree::startBackgroundMovesIfNeeded()::{lambda()#1}, std::__1::allocator<{lambda()#1}>, DB::BackgroundProcessingPoolTaskResult ()>::operator()() ()
          
          
            #4  0x000000000ff269df in DB::BackgroundProcessingPool::workLoopFunc() ()
          
          
            #5  0x000000000ff272cf in _ZZN20ThreadFromGlobalPoolC4IZN2DB24BackgroundProcessingPoolC4EiRKNS2_12PoolSettingsEPKcS7_EUlvE_JEEEOT_DpOT0_ENKUlvE_clEv ()
          
          
            #6  0x000000000930b8bd in ThreadPoolImpl<std::__1::thread>::worker(std::__1::__list_iterator<std::__1::thread, void*>) ()
          
          
            #7  0x0000000009309f6f in void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void ThreadPoolImpl<std::__1::thread>::scheduleImpl<void>(std::__1::function<void ()>, int, std::__1::optional<unsigned long>)::{lambda()#3}> >(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void ThreadPoolImpl<std::__1::thread>::scheduleImpl<void>(std::__1::function<void ()>, int, std::__1::optional<unsigned long>)::{lambda()#3}>) ()
          
          
            #8  0x00007ff91f4d5ea5 in start_thread () from /lib64/libpthread.so.0
          
          
            #9  0x00007ff91edf2b0d in clone () from /lib64/libc.so.6
          
        

多次抓取BgMoveProcPool線程都在執(zhí)行selectPartsForMove方法，說明selectPartsForMove方法耗時很長，通過方法名可以了解這個方法是在查找可以move的Part，接著查詢system.part_log表查看MovePart的記錄。

          
            SELECT * FROM system.part_log WHERE event_time > now() - toIntervalDay(1) AND event_type = 'MovePart'
          
        

執(zhí)行上述SQL查詢最近一天的MovePart的記錄，沒有匹配到一條。到這里我們幾乎可以確定BgMoveProcPool線程一直在查詢可以移動的Part，但結(jié)果都空，CPU一直在做無效的計算。根據(jù)上面的分析已經(jīng)定位到出現(xiàn)問題的代碼，接下來就是研究selectPartsForMove的源碼，如下：

          
            bool MergeTreePartsMover::selectPartsForMove(MergeTreeMovingParts & parts_to_move, const AllowedMovingPredicate & can_move, const std::lock_guard<std::mutex> & /* moving_parts_lock */) {
          
          
                std::unordered_map<DiskPtr, LargestPartsWithRequiredSize> need_to_move;
          
          
                ///  1. 遍歷所有的disk，將使用率超過閥值的disk添加need_to_move中
          
          
                if (!volumes.empty()) {
          
          
                    for (size_t i = 0; i != volumes.size() - 1; ++i) {
          
          
                        for (const auto & disk : volumes[i]->getDisks()) {
          
          
                            UInt64 required_maximum_available_space = disk->getTotalSpace() * policy->getMoveFactor(); /// move_factor默認0.9
          
          
                            UInt64 unreserved_space = disk->getUnreservedSpace();
          
          
                            if (unreserved_space < required_maximum_available_space)
          
          
                                need_to_move.emplace(disk, required_maximum_available_space - unreserved_space);
          
          
                        }
          
          
                    }
          
          
                }
          
          
                /// 2. 遍歷所有的part，首先如果Part的MoveTTL已過期則添加到需要移動的集合parts_to_move中，否則為超過閾值的disk添加候選Part
          
          
                time_t time_of_move = time(nullptr);
          
          
                for (const auto & part : data_parts) {
          
          
                    /// 檢查該part能否被move, 
          
          
                    if (!can_move(part, &reason))
          
          
                        continue;
          
          
            
              

          
          
            
              

          
          
                    /// 檢查part的move_ttl
          
          
                    auto ttl_entry = data->selectTTLEntryForTTLInfos(part->ttl_infos, time_of_move);
          
          
                    auto to_insert = need_to_move.find(part->volume->getDisk());
          
          
                    if (ttl_entry) { /// 已過期，則需要移動到目標(biāo)磁盤
          
          
                        auto destination = data->getDestinationForTTL(*ttl_entry);
          
          
                        if (destination && !data->isPartInTTLDestination(*ttl_entry, *part))
          
          
                            reservation = data->tryReserveSpace(part->getBytesOnDisk(), data->getDestinationForTTL(*ttl_entry));
          
          
                    }
          
          
                    if(reservation) /// 需要移動
          
          
                        parts_to_move.emplace_back(part, std::move(reservation));
          
          
                    else {  /// 候選Part
          
          
                        if (to_insert != need_to_move.end())
          
          
                            to_insert->second.add(part);
          
          
                    }
          
          
                }
          
          
                /// 3. 為候選的Part申請空間并添加到需要移動的集合parts_to_move中
          
          
                for (auto && move : need_to_move) {
          
          
                    for (auto && part : move.second.getAccumulatedParts()) {
          
          
                        auto reservation = policy->reserve(part->getBytesOnDisk(), min_volume_index);
          
          
                        if (!reservation)
          
          
            ????????????????break;
          
          
            
              

          
          
                        parts_to_move.emplace_back(part, std::move(reservation));
          
          
                        ++parts_to_move_by_policy_rules;
          
          
                        parts_to_move_total_size_bytes += part->getBytesOnDisk();
          
          
                    }
          
          
                }
          
        

SelectPartsForMove方法主要做3件事：

• 首先遍歷所有的disk，將使用率超過閥值的disk添加到need_to_move中。

• 然后遍歷所有的part，首先如果Part的MoveTTL已過期則添加到需要移動的集合parts_to_move中，否則為超過閾值的disk添加候選Part。

• 最后為候選的Part申請空間并添加到需要移動的集合parts_to_move中。

  
  

其中耗時最長的是第二步，會隨著表Part數(shù)的增加而增加，接著查詢了system.parts，發(fā)現(xiàn)總共有30多萬的part，最大的表有6萬多個part，為什么那么耗時就不奇怪了。

到這里問題就很明顯了，BgMoveProcPool線程不斷的在檢查這30多萬個part是否符合移動的條件，但每次都沒有一個part符合條件，一直在做無效的計算。

03

解決問題

線上節(jié)點磁盤空間很充足且未設(shè)置數(shù)據(jù)的冷熱分層，就不需要浪費CPU去檢查每個part。

當(dāng)沒有磁盤使用率達到90%得到的need_to_move為空，沒有設(shè)置冷熱分層，即move_ttl為空，當(dāng)兩個條件都成立的時候是不是就可以不用去檢查所有的part，就能節(jié)省大量的重復(fù)計算了，于是在遍歷檢查part之前添加下面兩行代碼，當(dāng)need_to_move為空且move_ttl為空，就直接返回false。

          
            if (need_to_move.empty() && !metadata_snapshot->hasAnyMoveTTL())
          
          
                return false;
          
        

04

實際效果

發(fā)布到國內(nèi)公共集群，接著使用top命令觀察各個線程消耗的CPU，可以發(fā)現(xiàn)在前面已經(jīng)找不到BgMoveProcPool線程了，8個BgMoveProcPool線程占用的CPU也從之前的30%左右都降到了4%以下。

再來觀察一下機器整體的CPU，可以清晰的發(fā)現(xiàn)CPU由升級前的20%左右降到了10%左右，并且尖刺沒那么高了。

并將這個優(yōu)化貢獻給了社區(qū)，已經(jīng)被merge到master。

05

后續(xù)思考

很多時候代碼在數(shù)據(jù)量小、并發(fā)低的時候不會有問題，一旦數(shù)據(jù)量、并發(fā)上來了就會出現(xiàn)很多問題，在寫代碼的過程中敬畏每一行代碼，讓程序更加健壯。后續(xù)Clickhouse將持續(xù)在日志檢索場景發(fā)力，打造穩(wěn)定、低成本、高吞吐、高性能的PB級日志檢索系統(tǒng)。?