Clickhouse 踩坑之旅 ---- MergeTree不合并分区的问题

1 、背景

	> 目前使用 ck 作日志存储用 大概1/s 到 10000/s 数据量不等 我们本地测试没问题 但是部署到客户环境报错
	> 错误信息是在插入数据时 Too many parts(300)

2、解决思路及路线

• 准备

模拟客户的硬件软件环境 取到日志样本

• 第一阶段

首先看到错误了 肯定是按照对应错误去找解决方法 第一反应既然这个值比较少 那么就给他调大
果然数据可以继续录入了 不过在尝试了 600、1200、9000后发现 治标不治本

• 第二阶段

发生错误的时候进入ck 存放数据目录 发现很多分区没有合并 而且总是在卡到一定数量时就不动了
然后就会报错 了解mergeTree的都知道 mergeTree 有个强制合并分区的命令 但是执行了也没有用
再次思考 是不是插入数据的时候 io 消耗过大 导致没有额外IO去执行合并呢
是否考虑增加 buffer 引擎的表挡在 mergeTree 之前就能解决问题呢 不过这个改动过于巨大 还是要确定问题再决定是否这么改 并且 buffer 引擎也有自己的缺点

• 第三阶段

观察：执行 iostat -d -x 1 命令观察io 发现服务器配置很高 并不会吃满IO 但是还是会出现这个问题。

• 第四阶段

突然想起ck 有自己的异常日志 再次模拟数据测试 发现 ck 报错 code 76
这一看像linux 打开资源过多的问题啊 但是此时并没有报错Too many parts(300)
过了一会 Too many parts(300) 再次出现
思考发生问题的原因 应该是mergeTree 合并分区时发现打开文件数量过多 无法进行合并 然后分区累积 导致Too many parts(300)

• 第五阶段

有问题 就要找解决方法了
修改/etc/security/limits.conf 添加：
clickhouse soft nofile 262144
clickhouse hard nofile 262144
使用ulimit -n 查询、看到的是所有用户可打开的总数，而ck能打开的大小只是系统的默认值，所以不要被这个命令干扰，重启ck后、获取ck的进程、再通过cat /proc/${pid}/limits |grep open ，判断配置是否生效

• 观察

修改后观察 发现错误解决 胜利的喜悦充满内心

3、总结

其实 第一时间去找ck 日志可能会快一些发现问题 这次问题解决 零零散散前后花了差不多两三天时间
也是给自己敲了一记警钟 如果真的冲动 用buffer 引擎改了 也许确实会修正问题 但是也给程序带来了很大的问题