【数据库维护】如何解决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问题同样可以参考上述配置调整。

相关推荐
pFg0v4O7P4 分钟前
从Cursor迁移到Claude Code:完整过渡指南
数据库
W001hhh11 分钟前
260615PM
数据库
吴声子夜歌20 分钟前
SQL经典实例——元数据查询
数据库·sql
睡不醒男孩0308231 小时前
生产环境故障销账:PostgreSQL 突发连接数暴涨与死锁,如何利用 CLup 秒级定位与解锁?
运维·数据库
2601_962054951 小时前
终端与IDE形态的vibe coding实测:两款AI编程工具迭代能力对比
数据库·ide·ai编程
万岳科技1 小时前
教育培训系统开发流程详解:平台建设关键环节解析
数据库·后端·学习
Nturmoils1 小时前
线上修一批脏数据,先别急着全量重来
数据库·后端
吴声子夜歌1 小时前
SQL经典实例——处理字符串
数据库·sql
睡不醒男孩0308232 小时前
PostgreSQL 数据库运维转型:从传统模式到 CLup 平台的 25 个核心 FAQ
运维·数据库·postgresql
凡人叶枫2 小时前
Effective C++ 条款40:明智而审慎地使用多重继承
java·数据库·c++·嵌入式开发·effective c++