clickhouse 生产集群部署之坑坑洼洼

最新推荐文章于 2024-07-28 21:09:15 发布

置顶喜欢吃燕麦粥的KeyL

最新推荐文章于 2024-07-28 21:09:15 发布

阅读量7.6k

点赞数 12

分类专栏： clickhouse 文章标签：大数据

本文链接：https://blog.csdn.net/aaa8210/article/details/103368788

版权

clickhouse 专栏收录该内容

16 篇文章

订阅专栏

之前看过ck中文社区，看到了很多莫名其妙的Exception 但并没有解答。自己测试集群小量数据抽取也没有遇到这些问题。

果不其然，生产集群部署都跳了一遍

新增相关配置：网上找的，与我原本的配置的一些不同点

<receive_timeout>800</receive_timeout>
<send_timeout>800</send_timeout>
<keep_alive_timeout>300</keep_alive_timeout>
<default_session_timeout>300</default_session_timeout>

我也没有添加的配置：
<merge_tree>
   <parts_to_delay_insert>300</parts_to_delay_insert>
   <parts_to_throw_insert>600</parts_to_throw_insert>
   <max_delay_to_insert>2</max_delay_to_insert>
   </merge_tree>

报错大致信息：

1.Too many parts (606). Merges are processing significantly slower than inserts

2. ERROR server.TransportRequestHandler: Error while invoking RpcHandler#receive() for one-way message.

3.read time out

4.ERROR cluster.YarnScheduler: Lost executor 174 on hadoop1: Container marked as failed: container_xx on host: hadoop1.
Exit status: 143. Diagnostics: Container killed on request.

5.DB::Exception: Possible deadlock avoided. Client should retry. (version 19.15.3.6 (official build)) (from [::1]:38736) (in query: SELECT * FROM dwd_ms_complex_detail_di_cluster LIMIT 1), Stack trace:

问题描述：

1.merge速度跟不上插入速度，也就是insert，可能原因：数据是否可能跨多个分区，如果这样的话每次写入有多个partition， merge压力很大

2.同1一起处理，可适当减少并发，同时修改numpartition

3.超时问题，可适当增加超时时间并添加 socketTimeout=600000 具体数自己测

4.yarn资源问题单个excutor 内存不足处理不过来，适当减少批次量（此处是waterdrop 设置的默认 20000 因为ck大批量小批次特性并结合yarn资源我设置了500000）

5.可能是truncate table导致数据删除不完全，解决方法：去存储位置，删数据吧