干货收藏|Clickhouse 常见问题及解决方案汇总
常见问题
偶尔出现 CLOSE_WAIT 情况
CLOSE_WAIT 占用的是网络端口资源,一台机器可以有6万多个端口,如果偶尔有 CLOSE_WAIT 的情况,也不用太着急 ,只要 CLOSE_WAIT 不是迅速持续地增加,一般来说该情况也会在数小时后被系统回收掉。
频繁出现 CLOSE_WAIT 情况
如果系统有大量CLOSE_WAIT,主要表现是在有句柄操作时会报"too many open files" 的问题,这时候服务不可访问,甚至 SSH 都连不上。 但"too many open files" 的问题也有可能是打开的文件句柄太多导致,即 ClickHouse 写入太频繁或者查询的时候经常要查大量的历史数据。
出现"too many parts" 情况
"too many parts" 一般是 ClickHouse 写入太频繁,导致 Parts 没有及时合并引起的,也有可能有大查询导致磁盘 IO 被占用而受影响。
出现"too many simultaneous queries" 情况
"too many simultaneous queries" 表面上来看是查询并发引起的,但通常情况下也有可能是因为有 大查询占用了大量的磁盘,导致很多查询请求堆积而超过了阈值引发的。
ClickHouse 里的并发请求都是存在 processes 表中,所有待执行与正在执行的请求均在该表中,当请求执行完之后便会被清除。出现"too many simultaneous queries" 错误时,便是根据这张表中求求的数量和 config.xml 的 max_concurrent_queries参数来对比的,如果 processes 中的数量超过了 max_concurrent_queries,就会报 "too many simultaneous queries",该现象可以理解为一种限流的保护机制。如果一个请求执行花了很长时间,它在processes表中待的时间就很长,如果很多请求均出现这样的情况,那么 processes 中的记录就有可能超过 max_concurrent_queries。
Clickhouse 的 CPU 使用率与 CPU Load 飙升
大查询引起
包括Join查询、未带分区的查询、表结构定义没有使用好分区和主键、实际数据量过大、并发查询、Bug等;
ClickHouse 副本同步引起
故障描述
- Clickhouse 节点意外挂掉重启后 CPU Load 值持续飙升(超过 CPU 核数)无法恢复,节点不能正常提供服务,同步数据处于卡死状态;
- 查询集群中每个节点的 system.replication_queue,存在异常 MERGE_PARTS 类型任务,日志中有 "No active replica has part ... or covering part" 报错信息。
处理办法
问题出现的原因为 Clickhouse V20 有相关 Bug。当一些副本中有 Parts 丢失,此时副本同步队列中有异常任务时则会导致副本之前的同步出现死锁现象,具体处理步骤如下: 在集群中每个节点上,通过 clickhouse-clinet 连接后, 查询 system.replication_queue 表,看有无异常任务;
SELECT * FROM system.replication_queue WHERE create_time < now() - INTERVAL 1 DAY AND type = 'MERGE_PARTS' AND last_exception LIKE '%No active replica has part%' \G
如果节点存在上述异常任务,执行下面的 SQL 查出 zookeeper 上的 Path;
SELECT replica_path || '/queue/' || node_name FROM system.replication_queue JOIN system.replicas USING (database, table) WHERE create_time < now() - INTERVAL 1 DAY AND type = 'MERGE_PARTS' AND last_exception LIKE '%No active replica has part%'
类似:
在 shell 中执行下面的命令,将队列中异常任务的 path 输出到 clickhouse_exception.log 文件中;
clickhouse-client --query "SELECT replica_path || '/queue/' || node_name FROM system.replication_queue JOIN system.replicas USING (database, table) WHERE create_time < now() - INTERVAL 1 DAY AND type = 'MERGE_PARTS' AND last_exception LIKE '%No active replica has part%'" > clickhouse_exception.log
在 ClickHouse 集群对应的 Zookeeper 节点上,访问 ./zookeeper-shell.sh 127.0.0.1:2181,连接 zookeeper 后,按 clickhouse_exception.log 中记录的 path, 逐一执行删除 path 的操作。需注意,该操作非常危险,一定要确认 rmr 后面的路径与clickhouse_exception.log 中的路径一样。参考示例如下:
rmr /clickhouse/tables/1/docp/metrics/replicas/replica1/queue/queue-0000003433
当异常的 Path 删除完成后,在当前 ClickHouse 节点的 Clickhouse-client 中执行 SYSTEM RESTART REPLICAS
命令,使副本同步任务重启;
按上述步骤对其他节点进行处理,并再次检查已经处理过的节点。
解决思路
首先需分析故障情况是否为近期出现,如果是,则需查看近期是否有其他变更;
如果近期未有其他变更,则需要查看机器的 CPU 、网络、内存、磁盘等负载情况。程序在超负荷状态下会出现各种问题,因此,首先要将负荷降到正常状态再来排查问题;
机器负载异常,要从两方面分析。一方面有可能是程序异常引起了高负载,另一方面也有可能是高负载引起了程序异常,如果不好判断,则用排除法,可以卸载一些功能来看负载的变化;
如果当前故障为历史问题,则需回到问题初次显现的时间点来分析。
总结
程序是运行在OS 和硬件上的,程序和 OS 息息相关,程序的一些问题会反馈到 OS 的指标上,OS 上的指标也能看出来程序运行的一些问题,所以只有掌握如何看机器负载,对相关指标有清晰的认识才能更好的做好排障工作。通常下面这样情况均需要引起重视:
CPU Load5 及 Load10 超过 CPU 核数;
机器的空闲内存超过90%;
CPU 平均使用率超过90%;
磁盘使用率超过90%,磁盘 util 持续超过90%;
网络上传下载速率超过带宽的80%。
开源项目推荐
云智慧已开源数据可视化编排平台 FlyFish 。通过配置数据模型为用户提供上百种可视化图形组件,零编码即可实现符合自己业务需求的炫酷可视化大屏。 同时,飞鱼也提供了灵活的拓展能力,支持组件开发、自定义函数与全局事件等配置, 面向复杂需求场景能够保证高效开发与交付。
如果喜欢我们的项目,请不要忘记点击下方代码仓库地址,在 GitHub / Gitee 仓库上点个 Star,我们需要您的鼓励与支持。此外,即刻参与 FlyFish 项目贡献成为 FlyFish Contributor 的同时更有万元现金等你来拿。
GitHub 地址: https://github.com/CloudWise-OpenSource/FlyFish
Gitee 地址: https://gitee.com/CloudWise/fly-fish
微信扫描识别下方二维码,备注【飞鱼】加入 AIOps 社区飞鱼开发者交流群,与 FlyFish 项目 PMC 面对面交流~

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
高性能优惠叠加计算框架 Q-calculator 发布!
https://github.com/CyrilFeng/Q-calculator 优惠是营销转化链路的重要抓手,对刺激用户消费起到至关重要的作用,目前市场上的优惠主要包含活动(如拼多多的砍一刀、天猫农场、新用户首购、复购、积分等)和券(如折扣券、代金券、商品券、买A赠B等),复杂的优惠规则让用户很难自行计算优惠叠加的顺序,或许用户在复杂的优惠规则中降低购买商品的欲望,对于参加了多个活动、有多个优惠券情况尤为明显。 优惠的计算顺序可以分为平行式和渐进式,其中平行式优惠之间没有依赖关系,而渐进式优惠之间则存在依赖关系,即下一个优惠取决于上一步的优惠结果,假设小明消费了100元,有一个8折优惠券和一个满100-20的优惠券,则这2个优惠的使用顺序有以下两种情况: Q-calculator采用很多新颖的设计实现了高性能求解优惠最优排列。 核心计算类 Permutation Permutation是一个抽象类,是Q-calculator的核心,在Permutation中使用了很多优化策略来保证性能,这些策略包括: 预存的排列数结果集 这么设计的原因是在业务场景中需要频繁的计算排列,对于某个长度...
- 下一篇
前端监控系列4 | SDK 体积与性能优化实践
背景 字节各类业务拥有众多用户群,作为字节前端性能监控 SDK,自身若存在性能问题,则会影响到数以亿计的真实用户的体验。所以此类 SDK 自身的性能在设计之初,就必须达到一个非常极致的水准。 与此同时,随着业务不断迭代,功能变得越来越多,对监控的需求也会变得越来越多。例如,今天 A 业务更新了架构,想要自定义性能指标的获取规则,明天 B 业务接入了微前端框架,需要监控子应用的性能。在解决这些业务需求的同时,我们会不断加入额外的判断逻辑、配置项。同时由于用户的电脑性能、浏览器环境的不同,我们又要解决各种兼容性问题,加入 polyfill 等代码,不可避免地造成 SDK 体积膨胀,性能劣化。那么我们是如何在需求和功能不断迭代的情况下,持续追踪和优化 SDK 的体积和性能的呢? SDK 体积优化 通常而言,体积的优化是最容易拿到收益的一项。 由于监控 SDK 通常作为第一个脚本被加载到页面中,体积的膨胀不仅会增加用户的下载时间,还会增加浏览器解析脚本的时间。对于体积优化,我们可以从宏观和微观两个角度去实现。 微观上,我们会去尽可能去精简所有的表达,剥离冗余重复代码,同时尽可能减少以下写法的出...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Mario游戏-低调大师作品
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS7安装Docker,走上虚拟化容器引擎之路