ClickHouse内存问题排查与优化实战指南

1. ClickHouse内存问题排查全景指南

作为一款高性能列式数据库，ClickHouse在处理海量数据时展现出惊人的查询速度，但这也意味着它对内存管理有着极高的要求。在实际生产环境中，内存问题往往是导致ClickHouse性能下降甚至服务崩溃的首要原因。本文将系统性地介绍ClickHouse内存问题的排查方法，从业务层SQL分析到系统层内存分配，再到底层工具诊断，形成一套完整的排查体系。

2. 业务层排查：定位高消耗源头

2.1 实时查询监控与分析

当发现ClickHouse节点内存使用异常时，首要任务是识别当前正在消耗大量内存的查询。通过system.processes表可以获取实时查询的内存消耗情况：

sql复制SELECT
    hostname(),
    query_id,
    user,
    formatReadableSize(memory_usage) AS memory_used,
    elapsed,
    query
FROM clusterAllReplicas('ck_cluster', system.processes)
WHERE memory_usage > 0
ORDER BY memory_usage DESC
LIMIT 20;

注意：在生产环境中，建议添加LIMIT子句避免结果集过大。同时关注memory_usage大于1GB的查询，这些通常是需要重点优化的对象。

关键指标解读：

• memory_usage：查询当前占用的内存字节数
• elapsed：查询已执行时间，长时间运行的查询更可能积累高内存消耗
• query：完整的SQL文本，用于分析查询模式

2.2 历史查询峰值分析

除了实时监控，通过system.query_log表可以分析历史查询的内存使用情况，找出周期性的"内存杀手"：

sql复制SELECT
    argMax(hostName(), memory_usage) AS node_host,
    argMax(user, memory_usage) AS execution_user,
    formatReadableSize(max(memory_usage)) AS max_mem_readable,
    max(memory_usage) AS raw_max_mem,
    argMax(query_start_time, memory_usage) AS peak_time,
    round(argMax(query_duration_ms, memory_usage)/1000,2) AS duration_sec,
    argMax(query, memory_usage) AS worst_query,
    count() AS execution_count
FROM clusterAllReplicas('ck_cluster', system.query_log)
WHERE type = 'QueryFinish'
  AND event_time >= now() - INTERVAL 7 DAY
  AND memory_usage > 1e9  -- 筛选内存消耗大于1GB的查询
GROUP BY normalized_query_hash
ORDER BY raw_max_mem DESC
LIMIT 50;

分析技巧：

1. 关注max_mem_readable和duration_sec的组合，高内存长耗时的查询优先级最高
2. execution_count显示查询执行频率，高频查询即使单次内存不高，累积影响也可能很大
3. 按时间维度分析，找出是否有特定时间段的内存高峰

2.3 内存敏感表引擎检查

某些ClickHouse表引擎会持续占用内存，需要特别关注：

sql复制SELECT 
    database,
    name AS table_name,
    engine,
    formatReadableSize(total_bytes) AS size
FROM system.tables
WHERE engine IN ('Memory','Set','Join','Buffer')
  AND total_bytes > 0
ORDER BY total_bytes DESC;

常见内存表引擎特点：

• Memory：全内存表，数据不持久化
• Set：用于IN子查询优化的内存集合
• Join：JOIN操作的内存哈希表
• Buffer：写入缓冲表，数据会定期刷盘

实操建议：对于必须使用内存引擎的场景，建议设置max_size参数限制内存使用，并建立监控告警。

3. 系统层排查：内存组件分析

3.1 内存指标系统解读

ClickHouse通过两套系统表提供内存监控指标：

3.1.1 实时内存指标(system.metrics)

sql复制SELECT 
    hostname(),
    name, 
    value,
    formatReadableSize(value) AS size 
FROM clusterAllReplicas('ck_cluster', system.metrics) 
WHERE name LIKE '%Memory%' OR name LIKE '%Cache%'
ORDER BY value DESC 
LIMIT 20;

关键指标说明：

3.1.2 异步采集指标(system.asynchronous_metrics)

sql复制SELECT 
    hostname(),
    metric,
    value,
    formatReadableSize(value) AS readable_size
FROM clusterAllReplicas('ck_cluster', system.asynchronous_metrics)
WHERE metric LIKE '%Memory%' OR metric LIKE '%Cache%'
ORDER BY value DESC
LIMIT 20;

重点关注的异步指标：

1. MemoryResident：实际物理内存使用量(RSS)
2. MemoryVirtual：虚拟内存使用量(VIRT)
3. MarkCacheBytes：标记缓存大小
4. UncompressedCacheBytes：未压缩数据缓存大小
5. jemalloc.allocated：jemalloc分配的内存

3.2 内存分配采样分析

ClickHouse支持内存分配采样，可定位到具体函数级别的内存使用：

sql复制-- 检查内存采样配置
SELECT * FROM system.settings 
WHERE name LIKE '%memory_profiler%';

-- 分析内存分配热点
SELECT
    trace_type,
    count() AS alloc_times,
    formatReadableSize(sum(size)) AS total_size,
    arrayStringConcat(arrayMap(x -> demangle(addressToSymbol(x)), trace), '\n') AS stacktrace
FROM system.trace_log
WHERE event_date >= today() - 1
  AND trace_type = 'Memory'
GROUP BY trace_type, trace
ORDER BY total_size DESC
LIMIT 10;

解读技巧：

1. 关注频繁出现的大内存分配栈
2. 结合demangle后的函数名分析业务逻辑
3. 对比不同时间段的分配模式变化

4. 底层工具排查

4.1 jemalloc内存分析

ClickHouse默认使用jemalloc内存分配器，相关指标对诊断内存问题至关重要：

sql复制SELECT
    hostname(),
    metric,
    value,
    formatReadableSize(value) AS readable_value,
    description
FROM clusterAllReplicas('ck_cluster', system.asynchronous_metrics)
WHERE metric LIKE 'jemalloc%'
ORDER BY value DESC;

关键jemalloc指标解析：

4.2 操作系统级检查

除了ClickHouse自身指标，还需检查操作系统内存状态：

bash复制# 在ClickHouse服务器上执行
cat /proc/$(pidof clickhouse-server)/status | grep -i vm
free -h
cat /proc/meminfo | grep -i cache

关键系统指标对应关系：

5. 典型内存问题处理方案

5.1 查询内存限制配置

xml复制<!-- config.xml -->
<profiles>
    <default>
        <max_memory_usage>10000000000</max_memory_usage>  <!-- 10GB -->
        <max_memory_usage_for_user>20000000000</max_memory_usage_for_user>
        <max_untracked_memory>1048576</max_untracked_memory>
    </default>
</profiles>

关键参数说明：

• max_memory_usage：单个查询内存上限
• max_memory_usage_for_user：单用户总内存上限
• max_untracked_memory：未跟踪内存阈值

5.2 缓存调优建议

xml复制<!-- config.xml -->
<yandex>
    <mark_cache_size>8589934592</mark_cache_size>  <!-- 8GB -->
    <uncompressed_cache_size>8589934592</uncompressed_cache_size>
    <cache_policy>SLRU</cache_policy>
</yandex>

缓存优化原则：

1. Mark缓存设为可用内存的10-20%
2. 未压缩缓存根据查询模式调整
3. 监控缓存命中率(cache_hits/cache_misses)

5.3 内存问题排查流程

1. 紧急处理：

   • 终止高内存查询
   • 临时增加内存限制
   • 重启受影响节点

2. 根因分析：

   • 检查查询模式变化
   • 分析内存分配热点
   • 验证数据量增长

3. 长期优化：

   • 优化问题查询
   • 调整内存配置
   • 建立监控告警

6. 实战案例解析

6.1 案例一：聚合查询内存爆炸

现象：某聚合查询偶尔消耗50GB+内存导致OOM

分析过程：

1. 通过query_log发现该查询在大量GROUP BY时内存激增
2. 检查发现缺少optimize_aggregation_in_order设置
3. 存在高基数(high-cardinality)分组字段

解决方案：

sql复制SET optimize_aggregation_in_order=1;
ALTER TABLE target_table MODIFY SETTING index_granularity=8192;

6.2 案例二：jemalloc内存滞留

现象：查询停止后内存不释放，resident持续高位

诊断步骤：

1. jemalloc.retained持续增长
2. dirty_purged增长缓慢
3. 后台线程活跃但回收效率低

调优方案：

xml复制<yandex>
    <jemalloc>
        <dirty_decay_ms>10000</dirty_decay_ms>
        <background_thread>true</background_thread>
    </jemalloc>
</yandex>

6.3 案例三：JOIN引擎内存泄漏

现象：周期性内存增长，与JOIN表相关

排查方法：

1. 通过system.tables定位大JOIN表
2. 分析JOIN使用模式
3. 检查join_use_nulls配置

优化措施：

sql复制CREATE TABLE join_table (...) ENGINE = Join(...) SETTINGS join_use_nulls=0;
SET join_algorithm='auto';

7. 内存监控体系建议

完善的监控是预防内存问题的关键：

1. 基础监控：

   • 节点内存使用率
   • 查询内存消耗Top10
   • jemalloc分配情况

2. 高级监控：

   • 内存碎片率
   • 缓存命中率
   • 后台回收效率

3. 告警规则：

   • MemoryTracking > 80%物理内存
   • resident持续增长不释放
   • 单个查询内存超限

示例Prometheus监控指标：

yaml复制- name: clickhouse_memory
  rules:
  - record: clickhouse:memory_usage:ratio
    expr: sum(clickhouse_metric_MemoryTracking) by (instance) / on(instance) node_memory_MemTotal_bytes
    labels:
      severity: warning
    annotations:
      summary: "ClickHouse memory usage high (instance {{ $labels.instance }})"
      description: "ClickHouse is using {{ $value | humanizePercentage }} of system memory"

通过以上系统化的内存问题排查方法，结合实际情况灵活应用，可以有效解决ClickHouse环境中的各类内存问题，保障服务的稳定高效运行。