什么?部署ClickHouse的服务器CPU利用率100%了?

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 什么?部署ClickHouse的服务器CPU利用率100%了?

背景

   某客户现场的ClickHouse所在服务器资源占用率100%了,引发了服务器告警。观察Grafana监控面板发现,从12点左右出现了大量的碎片写入,从而引起了相关指标的快速上升。

   本文主要通过ClickHouse官方的系统表system.query_log表进行问题排查定位,结合Grafana监控面板最终定位到问题根本原因。

最近写入sql执行是否有异常,判断是否是因为批量的数据写入导致的CPU利用率突增

SELECT   
    event_time,   
    user,   
    query_id AS query,   
    read_rows,   
    read_bytes,   
    result_rows,   
    result_bytes,   
    memory_usage,   
    exception  
FROM clusterAllReplicas('cluster_name', system, query_log)  
WHERE (event_date = today()) AND (event_time >= (now() - 60)) AND (is_initial_query = 1) AND (query NOT LIKE 'INSERT INTO%')  
ORDER BY event_time DESC  
LIMIT 100

昨天有没有大于5分钟的慢查询

SELECT   
    event_time,   
    user,   
    query_id AS query,   
    read_rows,   
    read_bytes,   
    result_rows,   
    result_bytes,   
    memory_usage,   
    exception  
FROM clusterAllReplicas('cluster_name', system, query_log)  
WHERE (event_date = yesterday()) AND query_duration_ms > 30000 AND (is_initial_query = 1) AND (query NOT LIKE 'INSERT INTO%')  
ORDER BY query_duration_ms desc  
LIMIT 100

磁盘占用最高的前10张表

SELECT   
    database,   
    table,   
    sum(bytes_on_disk) AS bytes_on_disk  
FROM clusterAllReplicas('cluster_name', system, parts)  
WHERE active AND (database != 'system')  
GROUP BY   
    database,   
    table  
ORDER BY bytes_on_disk DESC  
LIMIT 10

查询频率前10的用户

SELECT   
    user,   
    count(1) AS query_times,   
    sum(read_bytes) AS query_bytes,   
    sum(read_rows) AS query_rows  
FROM clusterAllReplicas('cluster_name', system, query_log)  
WHERE (event_date = yesterday()) AND (is_initial_query = 1) AND (query NOT LIKE 'INSERT INTO%')  
GROUP BY user  
ORDER BY query_times DESC  
LIMIT 10

统计SQL 查询次数,判断哪次查询时间最长以及查询的平均时长

select
  left(query,
  100) as sql,
  count() as queryNum,
  sum(query_duration_ms) as totalTime,
  totalTime / queryNum as avgTime
from
  system.query_log ql
where
  event_time > toDateTime('2024-05-20 12:00:00')
  and event_time < toDateTime('2024-05-20 17:00:00')
group by
  sql
order by
  queryNum desc
limit 10

查询不包含insert into语句的5个小时查询次数超过1000次的 SQL

select
  *
from
  (
  select
    LEFT(query,
    100) as sql,
    count() as quneryNum,
    sum(query_duration_ms) as totalTime,
    totalTime / queryNum as avgTime
  from
    system.query_log ql
  where
    event_time > toDateTime('2024-05-20 12:00:00')
    and event_time < toDateTime('2024-05-20 17:00:00')
    and query not like '%INSERT INTO%'
  group by
    sql
  order by
    avgTime desc)
where
  queryNum > 1000
limit 50

由于上述 SQL均做了截取,故需根据所查询 SQL 进一步匹配 SQL。

select
  query
from
  system.query_log
where
  event_time > toDateTime('2024-05-20 12:00:00')
  and event_time < toDateTime('2024-05-20 17:00:00')
  and query like '%需要匹配的sql查询%'
limit 5;

是否有left join查询,如果大表进行left join查询很可能导致CPU过高

select
  *
from
  (
  select
    LEFT(query,100) as sql,
    count() as quneryNum,
    sum(query_duration_ms) as totalTime,
    totalTime / queryNum as avgTime
  from
    system.query_log ql
  where
    sql like '%前面定位到的sql的信息%'
    and read_rows != 0
    and event_time > toDateTime('2024-05-20 12:00:00')
    and event_time < toDateTime('2024-05-20 17:00:00')
    and query not like '%INSERT INTO%'
  group by
    sql
  order by
    queryNum desc)

根据小时聚合每个小时查询次数耗时

select
  toHour(event_time) as t,
  count() as queryNum,
  sum(query_duration_ms) as totalTime,
  totalTime / queryNum as avgTime
from
  system.query_log ql
where
  event_time > toDateTime('2024-05-20 08:00:00')
  and event_time < toDateTime('2024-05-20 17:00:00')
  and query not like '%INSERT INTO%'
  and query like '%前面定位到的sql的信息%'
  and read_rows != 0
group by
  t
limit 50

根据小时聚合每个分钟查询次数耗时

select
  toMinute(event_time) as t,
  count() as queryNum,
  sum(query_duration_ms) as totalTime,
  totalTime / queryNum as avgTime
from
  system.query_log ql
where
  event_time > toDateTime('2024-05-20 12:00:00')
  and event_time < toDateTime('2024-05-20 13:00:00')
  and query not like '%INSERT INTO%'
  and query like '%前面定位到的sql的信息%'
  and read_rows != 0
group by
  t
limit 50

left join查询个数

select
  *
from
  (
  select
    LEFT(query,100) as sql,
    count() as quneryNum,
    sum(query_duration_ms) as totalTime,
    totalTime / queryNum as avgTime
  from
    system.query_log ql
  where
    query like '% JOIN%'
    and read_rows != 0
    and event_time > toDateTime('2024-05-20 12:00:00')
    and event_time < toDateTime('2024-05-20 21:00:00')
    and query not like '%INSERT INTO%'
  group by
    sql
  order by
    queryNum desc)

发现有问题的表时,查询该表结构

show create table "shard1"."xxx_replica"

总结

遇到此类问题可先查看日志,首先在(Clickhouse 日志 Zookeeper 日志)日志中看能否找到有用的信息,例如直接报错信息等,如果在日志中找不到太多有用的信息的话,可以从下面入手。


一般遇到 CPU的load 值比较高的情况时,基本上都是因为查询引起的。当遇到这种问题时可先查询带有JOIN 的 SQL 语句是不是很多。


通过Grafana等监控工具,快速定位问题发生的时间段。


通过查询query_log表中的执行记录,分析是否有大查询、慢查询,找到具体的sql,条件允许的情况下可以停止大查询观察CPU的load值是否降低。(kill掉相关sql,KILL QUERY WHERE query_id='')


本次排查过程主要使用query_log表,下面为重要字段:


event_time — 查询开始时间.

query_duration_ms — 查询消耗的时间(毫秒).

read_rows— 从参与了查询的所有表和表函数读取的总行数.

query — 查询语句.

Clickhouse query_log 表中所有字段

  • type (Enum8) — 执行查询时的事件类型. 值:
  • 'QueryStart' = 1 — 查询成功启动.
  • 'QueryFinish' = 2 — 查询成功完成.
  • 'ExceptionBeforeStart' = 3 — 查询执行前有异常.
  • 'ExceptionWhileProcessing' = 4 — 查询执行期间有异常.
  • event_date (Date) — 查询开始日期.
  • event_time (DateTime) — 查询开始时间.
  • event_time_microseconds (DateTime64) — 查询开始时间(毫秒精度).
  • query_start_time (DateTime) — 查询执行的开始时间.
  • query_start_time_microseconds (DateTime64) — 查询执行的开始时间(毫秒精度).
  • query_duration_ms (UInt64) — 查询消耗的时间(毫秒).
  • read_rows (UInt64) — 从参与了查询的所有表和表函数读取的总行数. 包括:普通的子查询, IN 和 JOIN的子查询. 对于分布式查询 read_rows 包括在所有副本上读取的行总数。 每个副本发送它的 read_rows 值,并且查询的服务器-发起方汇总所有接收到的和本地的值。 缓存卷不会影响此值。
  • read_bytes (UInt64) — 从参与了查询的所有表和表函数读取的总字节数. 包括:普通的子查询, IN 和 JOIN的子查询. 对于分布式查询 read_bytes 包括在所有副本上读取的字节总数。 每个副本发送它的 read_bytes 值,并且查询的服务器-发起方汇总所有接收到的和本地的值。 缓存卷不会影响此值。
  • written_rows (UInt64) — 对于 INSERT 查询,为写入的行数。 对于其他查询,值为0。
  • written_bytes (UInt64) — 对于 INSERT 查询时,为写入的字节数。 对于其他查询,值为0。
  • result_rows (UInt64) — SELECT 查询结果的行数,或INSERT 的行数。
  • result_bytes (UInt64) — 存储查询结果的RAM量.
  • memory_usage (UInt64) — 查询使用的内存.
  • query (String) — 查询语句.
  • exception (String) — 异常信息.
  • exception_code (Int32) — 异常码.
  • stack_trace (String) — Stack Trace. 如果查询成功完成,则为空字符串。
  • is_initial_query(UInt8) — 查询类型. 可能的值:
  • 1 — 客户端发起的查询.
  • 0 — 由另一个查询发起的,作为分布式查询的一部分.
  • user (String) — 发起查询的用户.
  • query_id (String) — 查询ID.
  • address (IPv6) — 发起查询的客户端IP地址.
  • port (UInt16) — 发起查询的客户端端口.
  • initial_user (String) — 初始查询的用户名(用于分布式查询执行).
  • initial_query_id (String) — 运行初始查询的ID(用于分布式查询执行).
  • initial_address (IPv6) — 运行父查询的IP地址.
  • initial_port (UInt16) — 发起父查询的客户端端口.
  • interface (UInt8) — 发起查询的接口. 可能的值:
  • 1 — TCP.
  • 2 — HTTP.
  • 0 — TCP接口的查询.
  • 1 — GET
  • 2 — POST
  • http_user_agent (String) — The UserAgent The UserAgent header passed in the HTTP request。
  • quota_key (String) — 在quotas 配置里设置的“quota key” (见 keyed).
  • revision (UInt32) — ClickHouse revision.
  • ProfileEvents (Map(String, UInt64))) — Counters that measure different metrics. The description of them could be found in the table 系统。活动
  • Settings (Map(String, String)) — Names of settings that were changed when the client ran the query. To enable logging changes to settings, set the log_query_settings 参数为1。
  • thread_ids (Array(UInt64)) — 参与查询的线程数.
  • Settings.Names (Array(String)) — 客户端运行查询时更改的设置的名称。 要启用对设置的日志记录更改,请将log_query_settings参数设置为1。
  • Settings.Values (Array(String)) — Settings.Names 列中列出的设置的值
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
5天前
|
缓存 监控 负载均衡
提高服务器CPU使用率
提高服务器CPU使用率
47 7
|
5天前
|
存储 缓存 监控
如何提高服务器CPU性能?
如何提高服务器CPU性能?
30 3
|
14天前
|
存储 关系型数据库 MySQL
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
83 5
|
1月前
|
网络协议 网络安全
基于bind软件部署DNS服务器
关于如何使用bind软件部署DNS服务器的教程,包括DNS服务器的类型、基于bind软件的部署步骤、验证DNS服务器可用性的指导,以及如何进行DNS正向解析的实现。
34 2
基于bind软件部署DNS服务器
|
22天前
|
监控 JavaScript Java
部署应用程序到服务器
部署应用程序到服务器
39 3
|
1月前
|
存储 关系型数据库 MySQL
使用Docker快速部署Mysql服务器
本文介绍了如何使用Docker快速部署MySQL服务器,包括下载官方MySQL镜像、启动容器、设置密码、连接MySQL服务器以及注意事项。
185 18
|
1月前
|
算法 测试技术 AI芯片
CPU反超NPU,llama.cpp生成速度翻5倍!LLM端侧部署新范式T-MAC开源
【9月更文挑战第7天】微软研究院提出了一种名为T-MAC的创新方法,旨在解决大型语言模型在资源受限的边缘设备上高效部署的问题。T-MAC通过查表法在CPU上实现低比特LLM的高效推理,支持混合精度矩阵乘法,无需解量化。其通过位级查表实现统一且可扩展的解决方案,优化数据布局和重用率,显著提升了单线程和多线程下的mpGEMV及mpGEMM性能,并在端到端推理吞吐量和能效方面表现出色。然而,表量化和快速聚合技术可能引入近似和数值误差,影响模型准确性。论文详见:[链接](https://www.arxiv.org/pdf/2407.00088)。
83 10
|
15天前
|
JavaScript Linux 开发工具
如何将nodejs项目程序部署到阿里云服务器上
该文章详细描述了将Node.js项目部署到阿里云服务器的步骤,包括服务器环境配置、项目上传及使用PM2进行服务管理的过程。
|
22天前
|
Ubuntu 开发工具 git
在Ubuntu上部署BOA服务器的步骤
部署BOA服务器是一个涉及多个步骤的过程,包括系统更新、安装依赖、下载和编译源代码、配置服务器以及启动和验证。遵循上述步骤,可以在Ubuntu系统上成功部署BOA服务器,为开发和测试提供一个轻量级的Web服务器环境。
14 0
|
2月前
|
UED
JSF文件下载:解锁终极文件传输秘籍,让你的Web应用瞬间高大上!
【8月更文挑战第31天】掌握JSF文件下载功能对构建全面的Web应用至关重要。本文通过具体代码示例,详细介绍如何在JSF中实现文件下载。关键在于后端Bean中的文件读取与响应设置。示例展示了从创建实体类到使用`&lt;h:commandLink&gt;`触发下载的全过程,并通过正确设置响应头和处理文件流,确保文件能被顺利下载。这将显著提升Web应用的实用性与用户体验。
48 0