机器配置

Clickhouse 配置内存大小: 250G

Zookeeper 配置内存大小：24G

发现问题

企业相关开发人员通过Grafana监控Clickhouse指标观察到，从12点左右出现了大量的碎片写入，从而引起了相关指标的快速上升。查看云智慧的数字化运维数据平台 DODB （以下简称DODB）概览页也未查看出异常出现源头，而当查看服务器负载情况时，已经上升至900+。

开始排查

1. 检查是否为执行 SQL 太多

当遇到此类问题时，普遍情况下均会猜测是 SQL 执行太多导致。因此，团队开发人员检查了 Clickhouse 的 Process表，以此判断运行中的 SQL 是否过多。与此同时与算法部门的同事进行沟通，最终确认是通过 DODB 写入数据的。随后又查询了一下执行中的 SOL，发现两台机器上运行中的 SOL 不太均衡。

2. 查询 Clickhouse 日志

当查看 Clickhouse 日志时，看到有很多 warn 的日志，但并没有出现有价值的日志。

3. 查询 Zookeeper 日志

当查看 Zookeeper 日志时，发现数据同步有比较大的延迟，超过了1-2s。

排查同步数据延迟是因为需要判断是 load 值上来导致延迟还是因为延迟导致的 load 值上来。可能是一个大查询导致 load 值上来后，引起 Zookeeper 出现问题，从而导致数据无法同步出现数据堆积的情况。因此，在此时查看了监控的读写情况，是由于load值上来后导致写入变慢。

4. SQL 语句查询

在 Clickhouse 中，所有被执行 Query 均会记录到system.query_log表中。因此可通过该表监控集群的查询情况。以下列举几种用于监控的常用SQL。

最近查询

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

慢查询

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

Top10大表

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

Top10查询用户

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 查询

查询结果出来，查看所执行 SQL 具体情况，发现很多都是“异常容器”的。

下图为作战地图所查大屏表，且为 left JOIN 表。由于 life 的 JOIN 在网络及其他因素条件有要求，因此比刚才查询更消耗资源。随后通过时间段查询判断出现异常时间是否匹配，对比发现时间上有些差异。

查询 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("2022-09-23 12:00:00") and event_time < toDateTime("2022-09-23 17:00:00") group by sql order by queryNum desc limit 10

通过该 SQL 查询，发现 5 个小时 SQL 查询了将近 4 万次，且同类型查询执行次数均较高，平均执行时间也比较长。此外，也有许多 5 个小时执行两三千次的 SQL 查询，该类查询平均每次耗时均在二三十秒。

查询不包含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('2022-09-23 12:00:00') and event_time < toDateTime('2022-09-23 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('2022-09-23 12:00:00') and event_time < toDateTime('2022-09-23 17:00:00') and query like '%需要匹配的sql查询%' limit 5;

使用第三条 SQL 用 queryNum 排序，查询出执行次数多且平均耗时比较大的 SQL，随后定位 SQL。以第二条记录为例：5个小时查询了 38000+次，耗时12s，每分钟查 120+次。

使用第三条 SQL ，将 时间 范围改到上午8点到上午12查询。 查询结果对比发现，执行耗时在上午时均很短，但到中午12点以后就变的非常慢了。

由于之前查询发现有部分 left JOIN 的查询，故查询了“异常容器”的left JOIN 的查询,，随后将读取条数为0的排除掉。

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 '%异常容器%' and read_rows != 0 and event_time > toDateTime('2022-09-23 12:00:00') and event_time < toDateTime('2022-09-23 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('2022-09-23 08:00:00') and event_time < toDateTime('2022-09-23 17:00:00') and query not like '%INSERT INTO%' and query like '%异常容器%' 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('2022-09-23 12:00:00') and event_time < toDateTime('2022-09-23 13:00:00') and query not like '%INSERT INTO%' and query like '%异常容器%' and read_rows != 0 group by t limit 50

查询结果如下：10点开始有，12 点查询响应时间翻了10倍。

从32s开始，响应时间变为24s多，后面的时间也逐渐变长。

查询 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('2022-09-23 12:00:00') and event_time < toDateTime('2022-09-23 21:00:00') and query not like '%INSERT INTO%' group by sql order by queryNum desc)

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

show create table "shard_2"."cw_db_zabbix_metric_data01_replica"

经查询发现该表创建的比较差，order by 仅有一个 UUID。且该表 JOIN 的 SQL 也比较多，每次查询的读取的条数也特别大。

停掉 SQL ，观察结果

通过观察，发现有不少类似的 JOIN 的 SQL。当停掉一个异常容器指标的 SQL 时会发现 load 值有些许变化，偶尔会降到700多。由于指标管理都是通过 gatewayAPI 调用，停掉 SQL 最快的方法便是直接将 gatewayAPI 停掉，这样只会影响指标 SQL 调，不会影响其他功能使用。将 gatewayAPI 停掉后就不会出现指标调用 SQL 也全部停掉，此时发现 load 值已降低

总结

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

一般遇到 load 值比较高的情况时，基本上都是发生在查询上面。当遇到这种问题时可先查询带有JOIN 的 SQL 语句是不是很多。随后通过 query_log 表中的一些字段去查询重要信息，通过对字段使用一些函数来获取有用的信息，如获取查询的 SQL，SQL 执行次数、执行时间等。

本次排查过程主要使用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.

• os_user (String) — 运行 clickhouse-client的操作系统用户名.

• client_hostname (String) — 运行clickhouse-client 或其他TCP客户端的机器的主机名。

• client_name (String) — clickhouse-client 或其他TCP客户端的名称。

• client_revision (UInt32) — clickhouse-client 或其他TCP客户端的Revision。

• client_version_major (UInt32) — clickhouse-client 或其他TCP客户端的Major version。

• client_version_minor (UInt32) — clickhouse-client 或其他TCP客户端的Minor version。

• client_version_patch (UInt32) — clickhouse-client 或其他TCP客户端的Patch component。

• http_method (UInt8) — 发起查询的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 列中列出的设置的值

开源项目推荐

云智慧已开源数据可视化编排平台 FlyFish 。通过配置数据模型为用户提供上百种可视化图形组件，零编码即可实现符合自己业务需求的炫酷可视化大屏。 同时，飞鱼也提供了灵活的拓展能力，支持组件开发、自定义函数与全局事件等配置， 面向复杂需求场景能够保证高效开发与交付。

如果喜欢我们的项目，请不要忘记点击下方代码仓库地址，在 GitHub / Gitee 仓库上点个 Star，我们需要您的鼓励与支持。此外，即刻参与 FlyFish 项目贡献成为 FlyFish Contributor 的同时更有万元现金等你来拿。

GitHub 地址： https://github.com/CloudWise-OpenSource/FlyFish

Gitee 地址： https://gitee.com/CloudWise/fly-fish

微信扫描识别下方二维码，备注【飞鱼】加入AIOps社区飞鱼开发者交流群，与 FlyFish 项目 PMC 面对面交流～