ClickHouse在高并发写入场景下的性能优化实践（CPU利用率飙升）

来源：这里教程网时间：2026-03-28 19:12:28 作者：

背景问题分析现象复述初步诊断源码分析优化方案1. 调整写入缓冲区大小2. 启用并行写入3. 优化分区策略压测验证测试结果对比生产部署经验总结

背景

最近团队遇到了一个棘手的问题：我们的实时数据处理系统在峰值流量下出现了写入瓶颈，CPU 利用率飙升到 90%+，写入延迟从毫秒级变成了秒级。作为一个不信"玄学调优"的技术人，我决定深入剖析 ClickHouse 的写入机制，找出问题的根源。

问题分析

现象复述

峰值写入 QPS 达到 5 万时，ClickHouse 集群响应变慢部分写入操作超时，导致数据丢失风险节点 CPU 使用率持续高位，内存使用正常

初步诊断

我首先查看了 ClickHouse 的系统表，重点关注 system.metrics 和 system.events：

SELECT * FROM system.metrics WHERE metric LIKE '%Write%' OR metric LIKE '%Insert%'; SELECT * FROM system.events WHERE event LIKE '%Write%' OR event LIKE '%Insert%' ORDER BY value DESC LIMIT 20;

通过分析，我发现了几个关键指标异常：

WriteBufferFromFileDescriptorWriteBytes 增长速度异常

InsertedRows 与 InsertedBytes 的比例不符合预期

MergeTreeDataWriter 相关指标波动较大

源码分析

「源码之下，没有秘密。」我决定查看 ClickHouse 的写入相关源码，特别是 MergeTreeDataWriter 和 WriteBufferFromFile 部分。

在 MergeTreeDataWriter.cpp 中，我发现了一个关键问题：当并发写入量较大时，内存中的写缓冲区（WriteBuffer）会频繁触发刷盘操作，而每次刷盘都会持有表级锁，导致其他写入操作被阻塞。

// 简化后的关键代码逻辑 void MergeTreeDataWriter::writeTempPart(...) { // 获取表级锁 auto lock = table->lockForShare(); // 写入数据到临时分区 // ... // 刷盘操作 writer->flush(); // 释放锁 }

优化方案

基于源码分析，我制定了以下优化方案：

1. 调整写入缓冲区大小

<profiles> <default> <max_insert_block_size>1048576</max_insert_block_size> <min_insert_block_size_rows>10000</min_insert_block_size_rows> <min_insert_block_size_bytes>10485760</min_insert_block_size_bytes> </default> </profiles>

2. 启用并行写入

<merge_tree> <max_part_loading_threads>4</max_part_loading_threads> <number_of_free_threads_in_pool_to_lower_max_size_of_merge>4</number_of_free_threads_in_pool_to_lower_max_size_of_merge> </merge_tree>

3. 优化分区策略

根据业务特点，将原来的按天分区改为按小时分区，减少单个分区的数据量：

CREATE TABLE events ( event_time DateTime, user_id UInt64, event_type String, data String ) ENGINE = MergeTree() PARTITION BY toHour(event_time) ORDER BY (event_time, user_id);