ClickHouse Exit Code 139 / SIGSEGV 排查手册与原理说明

ClickHouse Exit Code 139 / SIGSEGV 排查手册与原理说明

1. 现象总览

在 ClickHouse 运行过程中，可能出现如下现象：

• clickhouse-server 进程异常退出
• 操作系统或容器显示Exit Code 139
• ClickHouse 日志中出现：

Received signal 11 Signal description: Segmentation fault

这类问题通常不是 SQL 语法错误，也不是普通资源不足，而是 ClickHouse 内部代码在运行时访问了非法内存地址，属于Fatal Crash级别问题。

2. 基础原理说明

2.1 什么是 Exit Code 139

在 Linux 系统中：

• Exit Code = 128 + Signal Number
• Signal 11 = SIGSEGV（段错误）

因此：

Exit Code 139 = 程序收到 SIGSEGV 信号后崩溃退出

SIGSEGV 表示：

• 进程尝试读取或写入不允许访问的内存区域
• 属于不可恢复错误

2.2 ClickHouse 为什么会 SIGSEGV

ClickHouse 是高度并发、向量化执行的 C++ 程序，SIGSEGV 通常来源于：

• 内部执行 pipeline 的 bug
• 多线程并发访问内存时的越界/悬空指针
• 已知版本缺陷（尤其是非 LTS 版本）

⚠️重要认知：

SIGSEGV ≠ 用户 SQL 写错

SIGSEGV = ClickHouse 内部程序缺陷（官方认可需升级处理）

3. 日志特征与关键判断点

3.1 典型 Fatal 日志结构

<Fatal> BaseDaemon: Received signal 11 <Fatal> BaseDaemon: Signal description: Segmentation fault <Fatal> BaseDaemon: Address: 0xXXXXXXXX <Fatal> BaseDaemon: Stack trace: ...

关键判断点：

3.2 常见 Crash Stack 特征（示例）

DB::ColumnString::prepareForSquashing DB::Squashing::squash DB::PipelineExecutor::executeStep

含义：

• 崩溃发生在查询执行阶段
• 多见于 SELECT / JOIN / DISTINCT / UNION ALL
• 与 INSERT、Merge 无直接关系

4. 与 SQL 的关系分析

4.1 高风险 SQL 组合模式

以下 SQL 特征组合，在旧版本中更容易触发 crash：

• DISTINCT
• GLOBAL JOIN
• UNION ALL
• 大量 String / Nullable(String) 列
• 宽表 + 多 pipeline stage

这些操作会触发 ClickHouse 内部的：

SquashingChunksTransform（块合并/压缩阶段）

这是 ClickHouse pipeline 中对数据块进行重组的重要阶段，也是历史上 bug 较多的模块之一。

4.2 为什么不是内存不足

对比两类错误：

你的日志属于后者。

5. 官方诊断工具

5.1 system.crash_log（核心工具）

ClickHouse 官方提供系统表记录 crash 信息：

SELECT*FROMsystem.crash_logORDERBYevent_timeDESCLIMIT10;

可获得：

• 崩溃时间
• signal 类型
• 线程 ID
• query_id
• stack trace

这是官方唯一认可的 crash 诊断入口。

5.2 system.query_log（辅助分析）

用于确认：

• 是否每次都是同一类 SQL
• 是否与特定表 / 查询模板相关

6. 版本问题与官方态度

6.1 官方日志中的明确提示

ClickHouse version 24.8.7.41 is old and should be upgraded to the latest version.

这句话的含义非常明确：

• 官方已知该版本存在稳定性问题
• 不保证在旧版本上修复 crash
• 推荐升级作为唯一根治方案

6.2 ClickHouse 的版本策略（重要）

📌官方强烈建议生产使用 LTS

当前建议：

• 25.1 LTS 或更高

7. 标准排查流程（可直接执行）

本章节补充Kubernetes 场景下的标准排查手册，覆盖 Pod 状态、重启原因、历史日志与 ClickHouse 内部日志的完整链路。

Step 0：Kubernetes 维度快速确认（必做）

0.1 获取 Pod 状态

kubectl get pod -n<namespace>|grepclickhouse

重点关注：

• STATUS 是否为CrashLoopBackOff
• RESTARTS 是否持续增长

0.2 查看 Pod 详细信息（核心）

kubectl describe pod<clickhouse-pod>-n<namespace>

重点字段解释：

若看到：

Last State: Terminated Reason: Error Exit Code: 139

即可100% 确认是进程级崩溃。

0.3 查看上一次容器日志（非常关键）

kubectl logs<clickhouse-pod>-n<namespace>-c clickhouse --previous

说明：

• --previous（或-p）用于查看崩溃前那一刻的日志
• SIGSEGV 的 Fatal 日志只存在于 previous log 中

Step 1：确认 SIGSEGV

• 是否 Exit Code 139
• 是否 Received signal 11

✅ 是 → 进入 crash 流程

Step 2：容器内 ClickHouse 日志核查

2.1 进入容器

kubectlexec-it<clickhouse-pod>-n<namespace>-c clickhouse --bash

2.2 查看 ClickHouse Server 日志

# 主日志tail-n200/var/log/clickhouse-server/clickhouse-server.log# 错误日志（重点）tail-n200/var/log/clickhouse-server/clickhouse-server.err.log

重点关注关键词：

• <Fatal>
• Received signal 11
• Segmentation fault

2.3 核对崩溃时间轴

将以下三者时间对齐：

• Pod Last State Finished 时间
• clickhouse-server.err.log 中 Fatal 时间
• system.crash_log 记录时间

若三者一致，可确认非探针、非运维误杀。

Step 3：定位 crash SQL

• 查看 query_id
• 关联 system.query_log

Step 4：查看 system.crash_log

• 确认 stack trace
• 判断是否 pipeline / squash / string 相关

Step 5：对照版本

• 是否非 LTS
• 是否 <= 官方已知问题版本

Step 6：升级验证（最关键）

• 升级到最新 LTS
• 重跑原 SQL

若升级后不再复现，即可定性为版本缺陷

8. 官方级结论模板（可对外说明）

本次 ClickHouse 异常属于进程级崩溃（SIGSEGV / Exit Code 139），并非 SQL 语法或资源配置问题。崩溃发生在查询执行 pipeline 内部，属于 ClickHouse 旧版本中已知的稳定性缺陷。官方建议升级至最新 LTS 版本以规避该问题，升级后同类查询不再复现，问题已确认解决。

9. 常见误区澄清

• ❌ 调大内存参数
• ❌ 限制 max_threads
• ❌ 重写 SQL 规避（只能临时绕过）

✅唯一根治：升级版本

10. 结语

SIGSEGV 在 ClickHouse 中不是“调参数能解决”的问题，而是：

稳定性工程问题 = 版本治理问题

在生产环境中：

• 永远优先选择 LTS
• 遇到 crash 第一时间看版本，而不是 SQL