【数据库维护】如何解决Clickhouse数据库Too many parts报错

如何解决Clickhouse数据库Too many parts/memory exceed limit报错

问题现象

  • clickhouse数据库服务日志报错Too many parts.Merges are processing significantly slower than inserts exception.
  • clickhouse数据库服务报错memory exceed limit

问题原因分析

  1. 针对单张表单个分区频繁写入小数据量,数据库形成大量小碎片Parts,Clickhouse后台开始逐步进行小碎片合并为大碎片,消耗服务CPU/内存资源。
  2. 单张表单个分区活跃数据分片(Parts)数量大于服务配置参数parts_to_delay_insert值后,服务开始启动延迟插入,人为减慢新入库数据写入速度,进行自我保护,可能造成数据积压。
  3. 此时如果持续插入数据,单表单个分区活跃数据分片(Parts)数量大于服务配置参数parts_to_throw_insert参数,服务开始中断插入,报错Too many parts,造成数据丢失。
  4. clickhouse数据库为OLAP数据库,执行Alter/Update/Delete等操作会产生突变,对应表所有已入库数据在后台会自动重新入库,造成服务压力。

问题解决建议

  1. 优化查询/写入类操作

    1)单次写入同一分区数据 ,避免跨分区操作,资源消耗更大

    2)单次写入条数大于1W条 ,避免产生过多数据碎片,服务合并消耗资源

    3)避免变更表结构,以及更新/删除数据

  2. 优化clickhouse服务参数

    1)parts_to_delay_insert参数调整为1000,减缓延迟插入动作,避免数据积压

    2)parts_to_throw_insert参数调整为3000,减缓插入报错问题,避免数据丢失

    3)max_memory_usage参数调整,限制单次查询/插入内存使用上限

以上参数仅作参考,实际环境可以根据资源情况验证调整。

解决memory exceed limit问题同样可以参考上述配置调整。

相关推荐
Web3&Basketball几秒前
DeepSeek V4.1 Flash 实测:Token 砍半、Search API 跑通
数据库·人工智能·python·大模型·api调用·deepseek·推理优化
川石课堂软件测试3 分钟前
涨薪技术|0到1学会性能测试第9课-HTTP响应统计
数据库·功能测试·网络协议·http·kubernetes·单元测试·测试用例
竣达技术7 分钟前
Modbus 转 SNMP 协议转换器|自定义协议 + SNMP TRAP 主动上报
运维·服务器·网络·数据库·安全
ss2731 小时前
AI时代首先数据库-PostgreSQL实战笔记 | 18 PostgreSQL基本索引原理与创建
数据库·笔记·postgresql
l1t1 小时前
DeepSeek总结的本地优先的分析不需要数据库服务器
运维·服务器·数据库·人工智能·duckdb
十碗饭吃不饱1 小时前
MySQL InnoDB RR 隔离下二级索引临键锁引发 INSERT 锁超时 全链路解析
java·数据库·mysql
Gh0st_Lx1 小时前
【2】MySQL 为什么使用 B+树
数据库·b树·mysql
我不会插花弄玉1 小时前
8. 复合查询【由浅入深-MySQL】
android·数据库·mysql
北风toto1 小时前
数据库模式分解:如何判定“保持函数依赖”?
数据库