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
优化CK日志存储:从Toomanyparts到问题解决之旅

本文讲述了作者在部署CK日志存储时遇到的Toomanyparts错误,通过模拟环境、逐步排查,最终发现是文件打开数限制导致的合并分区问题。通过调整系统设置并优化配置,成功解决了日志写入问题。
最低0.47元/天 解锁文章
2508

被折叠的 条评论
为什么被折叠?



