当前位置： 首页 > news >正文

ClickHouse CPU 排查详细指南

news 2025/11/14 8:39:32

ClickHouse CPU 排查详细指南

📋 概述

本指南详细说明如何排查和解决 ClickHouse CPU 使用率过高的问题。CPU 高使用率通常由查询并发过多、慢查询、后台任务、数据导入等因素引起。

🔍 第一步：快速诊断

1.1 检查 CPU 使用率

# 方法1：使用 top 查看 ClickHouse 进程 CPU
top -p $(pgrep clickhouse-server)# 方法2：使用 htop（如果已安装）
htop -p $(pgrep clickhouse-server)# 方法3：使用 ps
ps aux | grep clickhouse-server | grep -v grep# 方法4：查看系统整体 CPU
mpstat -P ALL 1 5

正常值：CPU 使用率 < 70%
警告值：CPU 使用率 70-90%
危险值：CPU 使用率 > 90%

1.2 检查系统负载

# 查看系统负载
uptime# 查看详细负载信息
cat /proc/loadavg# 持续监控负载
watch -n 1 'uptime'

正常值：负载 < CPU 核心数
警告值：负载 = CPU 核心数 - 2倍
危险值：负载 > 2倍 CPU 核心数

🔍 第二步：检查当前运行的查询

2.1 查看所有正在执行的查询

clickhouse-client --query "
SELECT query_id,user,address,query,elapsed,read_rows,formatReadableSize(read_bytes) as read_bytes,formatReadableSize(memory_usage) as memory,formatReadableSize(read_bytes/elapsed) as read_speed
FROM system.processes 
WHERE query != ''
ORDER BY elapsed DESC
FORMAT Vertical
"

关键字段说明：

  • query_id：查询ID，可用于kill查询
  • elapsed：查询已执行时间（秒）
  • read_rows：已读取行数
  • read_bytes：已读取字节数
  • memory_usage：内存使用量

2.2 查看长时间运行的查询

# 查看执行时间超过10秒的查询
clickhouse-client --query "
SELECT query_id,user,query,elapsed,read_rows,formatReadableSize(read_bytes) as read_bytes
FROM system.processes 
WHERE query != '' AND elapsed > 10
ORDER BY elapsed DESC
"

2.3 查看查询的详细信息

# 查看特定查询的详细信息
clickhouse-client --query "
SELECT * 
FROM system.processes 
WHERE query_id = 'your-query-id'
FORMAT Vertical
"

2.4 统计并发查询数

# 统计当前并发查询数
clickhouse-client --query "
SELECT count() as concurrent_queries,sum(elapsed) as total_elapsed,sum(read_rows) as total_read_rows,formatReadableSize(sum(read_bytes)) as total_read_bytes
FROM system.processes 
WHERE query != ''
"

正常值：并发查询数 < CPU 核心数
警告值：并发查询数 = CPU 核心数 - 2倍
危险值：并发查询数 > 2倍 CPU 核心数

🔍 第三步：检查查询历史（慢查询）

3.1 查看最近的慢查询

# 查看最近100条执行时间超过1秒的查询
clickhouse-client --query "
SELECT query_id,user,query,query_start_time,query_duration_ms,read_rows,formatReadableSize(read_bytes) as read_bytes,formatReadableSize(memory_usage) as memory,result_rows,formatReadableSize(result_bytes) as result_size
FROM system.query_log 
WHERE type = 2 AND query_duration_ms > 1000AND event_time > now() - INTERVAL 1 HOUR
ORDER BY query_duration_ms DESC 
LIMIT 100
FORMAT Vertical
"

关键字段说明：

  • type = 2：表示查询完成（1=查询开始，2=查询结束）
  • query_duration_ms：查询执行时间（毫秒）
  • read_rows：读取的行数
  • result_rows：返回的结果行数

3.2 统计慢查询趋势

# 按小时统计慢查询
clickhouse-client --query "
SELECT toStartOfHour(event_time) as hour,count() as slow_queries,avg(query_duration_ms) as avg_duration_ms,max(query_duration_ms) as max_duration_ms,min(query_duration_ms) as min_duration_ms,sum(read_rows) as total_read_rows,formatReadableSize(sum(read_bytes)) as total_read_bytes
FROM system.query_log 
WHERE type = 2 AND event_time > now() - INTERVAL 24 HOURAND query_duration_ms > 1000
GROUP BY hour
ORDER BY hour DESC
"

3.3 找出最耗CPU的查询模式

# 按查询模式（去除具体值）统计
clickhouse-client --query "
SELECT normalizeQuery(query) as query_pattern,count() as query_count,avg(query_duration_ms) as avg_duration_ms,max(query_duration_ms) as max_duration_ms,sum(query_duration_ms) as total_duration_ms,sum(read_rows) as total_read_rows
FROM system.query_log 
WHERE type = 2 AND event_time > now() - INTERVAL 24 HOURAND query_duration_ms > 1000
GROUP BY query_pattern
ORDER BY total_duration_ms DESC
LIMIT 20
"

🔍 第四步：检查后台任务

4.1 查看合并任务（Merges）

# 查看所有正在进行的合并任务
clickhouse-client --query "
SELECT database,table,elapsed,progress,merge_type,merge_algorithm,num_parts_to_merge,total_rows_to_merge,formatReadableSize(total_bytes_to_merge) as total_size,formatReadableSize(bytes_read_uncompressed) as bytes_read,formatReadableSize(bytes_written_uncompressed) as bytes_written
FROM system.merges 
ORDER BY elapsed DESC
FORMAT Vertical
"

关键字段说明：

  • elapsed：合并已执行时间（秒）
  • progress：合并进度（0-1）
  • merge_type：合并类型（Regular, TTLDelete等）
  • total_bytes_to_merge：需要合并的总字节数

正常值：活跃合并任务数 < 5
警告值：活跃合并任务数 5-15
危险值：活跃合并任务数 > 15

4.2 查看 Mutation 任务

# 查看所有正在进行的Mutation任务
clickhouse-client --query "
SELECT database,table,mutation_id,command,create_time,is_done,latest_failed_part,latest_fail_time,latest_fail_reason
FROM system.mutations 
WHERE is_done = 0
ORDER BY create_time DESC
FORMAT Vertical
"

关键字段说明：

  • mutation_id：Mutation ID
  • command：执行的命令（如 ALTER TABLE … DELETE）
  • is_done：是否完成（0=进行中，1=完成）
  • latest_failed_part：最新失败的分区

正常值：活跃Mutation任务数 = 0
警告值：活跃Mutation任务数 1-3
危险值：活跃Mutation任务数 > 3

4.3 统计后台任务

# 统计活跃的后台任务
clickhouse-client --query "
SELECT 'Merges' as task_type,count() as active_count,sum(elapsed) as total_elapsed,formatReadableSize(sum(total_bytes_to_merge)) as total_size
FROM system.merges
UNION ALL
SELECT 'Mutations' as task_type,count() as active_count,0 as total_elapsed,'' as total_size
FROM system.mutations
WHERE is_done = 0
"

🔍 第五步：检查表和数据分区

5.1 查看表的分区信息

# 查看所有表的分区大小
clickhouse-client --query "
SELECT database,table,partition,count() as parts_count,sum(rows) as total_rows,formatReadableSize(sum(bytes_on_disk)) as total_size,min(modification_time) as oldest_part,max(modification_time) as newest_part
FROM system.parts 
WHERE active = 1
GROUP BY database, table, partition
ORDER BY sum(bytes_on_disk) DESC
LIMIT 50
"

5.2 查看表的压缩情况

# 查看表的压缩算法和压缩率
clickhouse-client --query "
SELECT database,table,format,count() as parts_count,sum(rows) as total_rows,formatReadableSize(sum(bytes_on_disk)) as compressed_size,formatReadableSize(sum(data_uncompressed_size)) as uncompressed_size,round(sum(data_uncompressed_size) / sum(bytes_on_disk), 2) as compression_ratio
FROM system.parts 
WHERE active = 1
GROUP BY database, table, format
ORDER BY sum(bytes_on_disk) DESC
LIMIT 30
"

压缩算法说明：

  • LZ4：速度快，CPU消耗低，压缩率中等（推荐）
  • ZSTD：压缩率高，但CPU消耗高
  • ZSTD(1-3)：低级别ZSTD，平衡压缩率和CPU

5.3 找出大分区

# 找出最大的分区
clickhouse-client --query "
SELECT database,table,partition,count() as parts,sum(rows) as rows,formatReadableSize(sum(bytes_on_disk)) as size,max(modification_time) as last_modified
FROM system.parts 
WHERE active = 1
GROUP BY database, table, partition
HAVING sum(bytes_on_disk) > 10737418240  -- 大于10GB
ORDER BY sum(bytes_on_disk) DESC
LIMIT 20
"

🔍 第六步：检查系统配置

6.1 查看并发相关配置

# 查看所有并发相关配置
clickhouse-client --query "
SELECT name,value,description
FROM system.settings 
WHERE name LIKE '%concurrent%' OR name LIKE '%thread%'OR name LIKE '%pool%'
ORDER BY name
"

关键配置：

  • max_concurrent_queries：最大并发查询数（推荐：CPU核心数）
  • max_thread_pool_size：线程池大小（推荐：CPU核心数*2）
  • max_insert_threads：插入线程数（推荐：4-8）
  • background_pool_size：后台任务线程数（推荐：16）

6.2 查看查询限制配置

# 查看查询限制配置
clickhouse-client --query "
SELECT name,value,description
FROM system.settings 
WHERE name LIKE '%max_%' AND (name LIKE '%query%' OR name LIKE '%memory%' OR name LIKE '%time%'OR name LIKE '%rows%'OR name LIKE '%bytes%')
ORDER BY name
"

关键配置：

  • max_execution_time：查询最大执行时间（秒）
  • max_memory_usage：单查询最大内存（字节）
  • max_rows_to_read：最大读取行数
  • max_bytes_to_read：最大读取字节数

6.3 查看合并相关配置

# 查看合并相关配置
clickhouse-client --query "
SELECT name,value,description
FROM system.settings 
WHERE name LIKE '%merge%'
ORDER BY name
"

关键配置：

  • max_bytes_to_merge_at_max_space_in_pool：合并最大字节数（推荐：150GB）
  • max_replicated_merges_in_queue：副本合并队列大小（推荐：16）

🛠️ 解决方案

方案1：优化查询并发

问题：并发查询过多
# 1. 查看当前并发数
clickhouse-client --query "SELECT count() FROM system.processes WHERE query != ''"# 2. 临时降低并发限制（在用户级别）
clickhouse-client --query "SET max_concurrent_queries=8"# 3. 永久修改（在config.xml中）
# <profiles>
#     <default>
#         <max_concurrent_queries>8</max_concurrent_queries>
#     </default>
# </profiles># 4. 或者kill长时间运行的查询
clickhouse-client --query "KILL QUERY WHERE query_id='xxx'"

方案2：优化慢查询

问题：慢查询导致CPU高
# 1. 找出慢查询
clickhouse-client --query "
SELECT query_id, query, query_duration_ms, read_rows
FROM system.query_log 
WHERE type=2 AND query_duration_ms > 5000
ORDER BY query_duration_ms DESC 
LIMIT 10
"# 2. 分析查询执行计划
clickhouse-client --query "EXPLAIN SELECT ..."  # 替换为实际查询# 3. 优化建议：
# - 添加合适的索引（ORDER BY字段）
# - 优化WHERE条件，减少扫描数据量
# - 使用PREWHERE替代WHERE（如果可能）
# - 减少SELECT的字段数量
# - 使用LIMIT限制返回结果
# - 避免全表扫描# 4. 设置查询超时
clickhouse-client --query "SET max_execution_time=60"  # 60秒超时

方案3：优化后台任务

问题：合并任务过多
# 1. 查看合并任务
clickhouse-client --query "SELECT * FROM system.merges ORDER BY elapsed DESC"# 2. 调整合并配置（在config.xml中）
# <merge_tree>
#     <max_bytes_to_merge_at_max_space_in_pool>161061273600</max_bytes_to_merge_at_max_space_in_pool>
#     <background_pool_size>16</background_pool_size>
# </merge_tree># 3. 等待合并完成或手动触发合并（谨慎使用）
clickhouse-client --query "OPTIMIZE TABLE database.table FINAL"
问题：Mutation任务卡住
# 1. 查看Mutation任务
clickhouse-client --query "SELECT * FROM system.mutations WHERE is_done=0"# 2. 如果Mutation卡住，可以取消（谨慎操作，可能导致数据不一致）
# clickhouse-client --query "KILL MUTATION WHERE database='xxx' AND table='xxx' AND mutation_id='xxx'"# 3. 避免在高峰期执行大量Mutation

方案4：优化压缩算法

问题：压缩算法CPU密集
# 1. 查看当前使用的压缩算法
clickhouse-client --query "
SELECT format, count() as parts, formatReadableSize(sum(bytes_on_disk)) as size
FROM system.parts 
WHERE active=1 
GROUP BY format
"# 2. 如果使用ZSTD，考虑改为LZ4（新表）
CREATE TABLE new_table (...
) ENGINE = MergeTree()
ORDER BY ...
SETTINGS index_granularity = 8192;# 3. 或者降低ZSTD压缩级别（新表）
CREATE TABLE new_table (column_name String CODEC(ZSTD(1))  -- 降低压缩级别
) ENGINE = MergeTree()
ORDER BY ...;# 4. 对于现有表，需要重建（数据量大时谨慎）
ALTER TABLE table_name MODIFY COLUMN column_name String CODEC(LZ4);

方案5：优化数据导入

问题：数据导入导致CPU高
# 1. 查看导入任务
clickhouse-client --query "SELECT query_id, query, elapsed FROM system.processes WHERE query LIKE '%INSERT%'"# 2. 降低插入并发
clickhouse-client --query "SET max_insert_threads=4"# 3. 使用批量插入
# 错误：INSERT INTO table VALUES (...); INSERT INTO table VALUES (...);
# 正确：INSERT INTO table VALUES (...), (...), (...);# 4. 使用异步插入（如果支持）
# INSERT INTO table ASYNC VALUES (...)

方案6：优化表结构

问题：表结构不合理导致查询慢
# 1. 检查ORDER BY字段是否合理
clickhouse-client --query "SHOW CREATE TABLE database.table_name"# 2. 优化建议：
# - ORDER BY字段应该是查询中常用的过滤字段
# - 添加合适的索引（ORDER BY字段）
# - 使用物化视图预聚合数据
# - 使用合适的表引擎（MergeTree vs ReplacingMergeTree等）# 3. 检查分区键
# 分区键应该选择经常用于过滤的字段（如日期）

📊 监控脚本

创建CPU监控脚本

#!/bin/bash
# clickhouse_cpu_monitor.shecho "=== ClickHouse CPU 监控 ==="
echo ""# 1. 系统CPU使用率
echo "1. 系统CPU使用率:"
top -bn1 | grep "Cpu(s)" | awk '{print "用户空间: " $2 "%", "内核空间: " $4 "%", "空闲: " $8 "%"}'
echo ""# 2. ClickHouse进程CPU
echo "2. ClickHouse进程CPU:"
CH_PID=$(pgrep clickhouse-server)
if [ -n "$CH_PID" ]; thentop -bn1 -p $CH_PID | tail -1 | awk '{print "CPU使用率: " $9 "%", "内存使用率: " $10 "%"}'
elseecho "ClickHouse进程未运行"
fi
echo ""# 3. 并发查询数
echo "3. 并发查询数:"
clickhouse-client --query "SELECT count() as concurrent_queries FROM system.processes WHERE query != ''"
echo ""# 4. 长时间运行的查询
echo "4. 长时间运行的查询 (>10秒):"
clickhouse-client --query "
SELECT query_id,elapsed,read_rows,formatReadableSize(read_bytes) as read_bytes
FROM system.processes 
WHERE query != '' AND elapsed > 10
ORDER BY elapsed DESC
LIMIT 5
"
echo ""# 5. 活跃合并任务
echo "5. 活跃合并任务:"
clickhouse-client --query "SELECT count() as active_merges FROM system.merges"
echo ""# 6. 活跃Mutation任务
echo "6. 活跃Mutation任务:"
clickhouse-client --query "SELECT count() as active_mutations FROM system.mutations WHERE is_done=0"
echo ""# 7. 最近1小时的慢查询统计
echo "7. 最近1小时慢查询统计 (>1秒):"
clickhouse-client --query "
SELECT count() as slow_queries,avg(query_duration_ms) as avg_duration_ms,max(query_duration_ms) as max_duration_ms
FROM system.query_log 
WHERE type=2 AND event_time > now() - INTERVAL 1 HOURAND query_duration_ms > 1000
"

保存为 clickhouse_cpu_monitor.sh，然后：

chmod +x clickhouse_cpu_monitor.sh
./clickhouse_cpu_monitor.sh

✅ 排查检查清单

  • 检查系统CPU使用率（top, htop）
  • 检查当前运行的查询（system.processes）
  • 检查慢查询历史（system.query_log）
  • 检查后台任务（system.merges, system.mutations）
  • 检查表和数据分区状态（system.parts）
  • 检查系统配置（system.settings）
  • 分析查询执行计划（EXPLAIN）
  • 优化慢查询SQL
  • 调整并发配置
  • 优化压缩算法
  • 监控CPU使用情况

💡 最佳实践

  1. 定期监控：设置定时任务监控CPU使用率
  2. 慢查询分析：定期分析慢查询日志，优化查询
  3. 合理配置：根据服务器配置合理设置并发数
  4. 选择压缩：根据场景选择压缩算法（LZ4 vs ZSTD）
  5. 避免高峰期：避免在业务高峰期执行大量后台任务
  6. 优化表结构：合理设计表结构，选择合适的ORDER BY字段
  7. 使用物化视图：使用物化视图预聚合数据，减少查询CPU消耗

记住：CPU高使用率通常是查询问题，先查查询，再查配置！ 🚀

http://www.dtcms.com/a/606034.html

相关文章：

  • 苍穹外卖 —— Spring Task和WebSocket的运用以及订单统一处理、订单的提醒和催单功能的实现
  • 专门做搞笑视频的网站泉州哪个公司网站做的好
  • 用DeepSeek 编写的BFS python求解程序测试出来的几个难解数独
  • 台州汇客网站建设wordpress 网址导航页面
  • leetcode 3228. 将 1 移动到末尾的最大操作次数 中等
  • 做设计那些网站可以卖设计图包装袋设计网站推荐
  • 做网站语言中国十大门户类网站
  • 广东省省考备考（第一百四十九天11.13）——言语、判断推理（强化训练）
  • 网站专题教程网站编辑做多久可以升职
  • ChatGPT无预告升级：GPT-5.1 来了，自适应推理、语气更自然、可语气设定
  • 网络文件系统（NFS）完全指南：从入门到实战
  • 婚恋APP小程序开发：Uniapp+SpringBoot全栈开发指南
  • Python进度条工具tqdm的安装与使用
  • 个人博客网站模板ui网页设计实习周报
  • 【计算机网络】[特殊字符] 408高频考点 | 数据链路层组帧：从字符计数到违规编码，一文学透四大实现方法
  • 第一次搭建个人主页+GitHub部署全记录：HTML/CSS/JS前端实现+留言板踩坑
  • 中山中小企业网站建设做电商运营需要具备什么能力
  • 音视频课程上传、加密与播放技术详解：知识付费系统源码开发实践
  • 专业做网站的域名官网
  • 网站响应式图片切换代码网站升级建设中
  • 理解 CSS 层叠上下文与 z-index — 从一个真实案例出发
  • 盘一盘Redis的底层数据结构
  • C++_chapter15_C++重要知识点_lambda,initializer_list
  • Collections工具类
  • 国家建设执业注册中心网站字体怎么安装到电脑wordpress
  • Android16 EDLA 开机向导的锁屏设置页面，HDMI out 鼠标不显示问题分析解决
  • 基于yolov8的SAR影像目标检测系统，支持图像、视频和摄像实时检测【pytorch框架、python源码】
  • 网站做直播功能需要注册吗腾讯广告投放平台官网
  • 网站空间 阿里云北京金山办公软件股份有限公司官网
  • 大丰有做网站的爱客crm官网