烂sql导致clickhouse集群memory_tracking直线飙升触发熔断

版 本 v e r s i o n   1 9 . 1 7 . 4 . 1 1     c l i c k h o u s e   集 群 , 主 要 存 日 志 数 据 与 监 控 数 据 。 架 构 为 4 台 主 机 1 2 个 实 例 数 , 数 据 为 单 副 本 。

近 日 , 该 c l i c k h o u s e 集 群 有 一 台 物 理 机 的 硬 件 ( 电 池 ) 损 坏 , 损 坏 的 硬 件 完 成 更 换 后 , 就 有 人 反 馈 数 据 查 询 异 常 , 报 D B : : E x c e p t i o n :   M e m o r y   l i m i t   ( t o t a l )   e x c e e d e d :   w o u l d   u s e   1 1 1 . 7 6   G i B   ( a t t e m p t   t o   a l l o c a t e   c h u n k   o f   5 7 6 6 8 8 0   b y t e s ) ,   m a x i m u m :   1 1 1 . 7 6   G i B  

报 错 指 向 内 存 , 看 查   c l i c k h o u s e _ m e m o r y _ t r a c k i n g   内 存 的 使 用 情 况 , 2 0 2 3 . 0 6 . 2 6   1 7 : 5 7   左 右   c l i c k h o u s e   集 群 各 个 节 点 c l i c k h o u s e _ m e m o r y _ t r a c k i n g 直 线 上 升 ( 除 了 硬 件 异 常 的 节 点 几 乎 始 终 为 0 ) , 最 终 迫 近 单 机 最 大 的 内 存 使 用 量   m a x _ m e m o r y _ u s a g e _ f o r _ a l l _ q u e r i e   的   1 2 0 G , 当 总 内 存 使 用 超 过 1 2 0 G 后 触 发 熔 断 , 中 断 请 求 , 也 就 是 上 文 提 到 的   M e m o r y   l i m i t   ( t o t a l )   e x c e e d e d

烂sql导致clickhouse集群memory_tracking直线飙升触发熔断_第1张图片

 

  c l i c k h o u s e _ g l o b a l _ t h r e a d _ a c t i v e   正 常 情 况 下 保 持 为 十 位 数 , 异 常 飙 升 至 5 千 多

烂sql导致clickhouse集群memory_tracking直线飙升触发熔断_第2张图片

 

异 常 时 间 段 c l i c k h o u s e _ q u e r y   请 求 也 有 波 动

烂sql导致clickhouse集群memory_tracking直线飙升触发熔断_第3张图片

 

2023-06-26 17:50:00 ~ 2023-06-26 18:08:00  这 段 时 间 c l i c k h o u s e 集 群 到 底 在 执 行 什 么 内 容

select query_start_time,query_duration_ms,address,read_rows,query from system.query_log where event_time  between toDateTime('2023-06-26 17:50:00') and toDateTime('2023-06-26 18:08:00') order by read_rows desc limit 10

获 取 到 的 有 用 信 息 , 有 人 执 行   ( 此 类 请 求 存 在 并 发 ) s e l e c t   *   f r o m   x x 1   U N I O N   A L L   s e l e c t   *   f r o m   x x 2   拼 接 最 近 半 年 数 据 的 烂 s q l , 相 当 于 是 1 8 2 个 表 U N I O N   A L L , 数 据 量 达 3 0 0 亿

烂sql导致clickhouse集群memory_tracking直线飙升触发熔断_第4张图片

 

异 常 时 间 段 c l i c k h o u s e 集 群 日 志 报 错   D B : : E x c e p t i o n :   C a n n o t   s c h e d u l e   a   t a s k   ( v e r s i o n   1 9 . 1 7 . 4 . 1 1   ( o f f i c i a l   b u i l d ) )   ( f r o m   1 7 2 . 2 6 . 1 8 5 . 1 8 6 : 5 1 7 0 8 )   ( i n   q u e r y :   S E L E C T   a p i   F R O M   i o v _ l o g . t _ i o v _ g w _ l o g _ l o c a l _ 2 0 2 3 0 1 2 7 ) ,   S t a c k   t r a c e , 指 向 硬 件 异 常 的 物 理 机   1 7 2 . 2 6 . 1 8 5 . 1 8 6

2023.06.26 17:57:30.120612 [ 34959 ] {a6ee5760-0b1c-410d-a6de-a5016425fe68}  executeQuery: Code: 439, e.displayText() = DB::Exception: Cannot schedule a task (version 19.17.4.11 (official build)) (from 172.26.185.186:51708) (in query: SELECT api FROM iov_log.t_iov_gw_log_local_20230127), Stack trace:

( 便 于 更 好 的 观 察 各 个 指 标 , 贴 一 张 核 心 指 标 汇 总 图 )

烂sql导致clickhouse集群memory_tracking直线飙升触发熔断_第5张图片

 

原 因 大 致 清 晰 了

1 7 2 . 2 6 . 1 8 5 . 1 8 6   物 理 机 硬 件 损 坏   - >   1 7 2 . 2 6 . 1 8 5 . 1 8 6   有 巨 烂 s q l 查 询   1 8 2 个 分 布 式 表 U N I O N   A L L , 总 数 据 量 达 3 0 0 亿   - >     触 发 1 7 2 . 2 6 . 1 8 5 . 1 8 6   c l i c k h o u s e _ l o c a l _ t h r e a d   线 程 飙 高   - >   触 发     c l i c k h o u s e _ g l o b a l _ t h r e a d _ a c t i v e   线 程 飙 高   - >   c l i c k h o u s e _ m e m o r y _ t r a c k i n g   飙 高   - >   达 到   m a x _ m e m o r y _ u s a g e _ f o r _ a l l _ q u e r i e   阈 值   - >   M e m o r y   l i m i t   ( t o t a l )   e x c e e d e d   报 错   - >   轮 询 重 启 c l i c k h o u s e 集 群 业 务 恢 复

优 化 点

1 、   c l i c k h o u s e _ g l o b a l _ t h r e a d _ a c t i v e   活 跃 线 程 数 监 控 告 警

2 、 c l i c k h o u s e _ m e m o r y _ t r a c k i n g   内 存 使 用 大 小 监 控 告 警

3 、 优 化   m a x _ m e m o r y _ u s a g   单 个 S Q L 在 单 台 机 器 最 大 内 存 使 用 量

4 、 约 束 烂 s q l

你可能感兴趣的:(bigdata错误解决,sql,clickhouse,数据库)