问题浅析：K8S某node节点负载飚升

IT那活儿 2023-10-16

192

点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！

问题现象

某K8S主机集群的node节点xxxxxxx在2023年8月2日13：31分,进程数达1万以上,5分钟平均负载在1600左右。

问题分析

2.1 资源使用情况分析

1）负载高前CPU使用率正常

2）负载高前内存使用率正常

3）负载高前IO等待及队列一直存在突增的情况

负载高前,存大大量的IO 写及队列等待。

2.2 Zabbix代理进程无法采集日志分析

1）Zabbix agent代理日志分析

代理一直有日志，说明进程正常。

2）Zabbix proxy日志分析

Proxy无法和agent通信的网络错误，说明此时代理已异常，以致于该设备在8月2日13:46后断采。

2.3 操作系统messages日志分析

1）触发缓存脏页数量全量从内存写入磁盘

Messages日志在8月2日13:03 报错hung_task_timeout_secs, INFO: task ps:70941 blocked for more than 120 seconds.触发文件系统缓存脏页数量从内存全量写入磁盘。

由于报错是kernel rwsem_down_read_failed+0x139/0x1c0，读写内存失败，不排除是kernel bug。

rwsem_down_read_failed+0x139/0x1c0

2）K8S集群所属主机分析 Master节点IO等待相对高。

问题原因总结：

1）平均负载高前,IO等待较K8S其它节点高，IO等待存在波峰波谷型，瞬间飚升的状态，写高达600M/s(新华三官测达1G多)。

可能是磁盘本身存在瓶颈。导致磁盘IO等待严重。表明业务写相对频繁。

2）102主机messages报错hung_task_timeout_secs, INFO: task ps:70941 blocked for more than 120 seconds.触发文件系统缓存脏页数量从内存全量写入磁盘，阻塞所有应用进程, 使所有应用进程等待，进而使平均负载达到2500多,进程达到12000。

由于主机无法登陆已重启，对应的block进程已释放，无法定位具体的应用进程，从报错的kernel rwsem_down_read_failed+0x139/0x1c0读写内存失败来看，也有可能是Kernel内核原因(有升级内核)。

备注：生产环境当前配置
vm.dirty_background_ratio = 10(当文件系统缓存脏页数量达到系统内存的10%时，触发pdflush/flush/kdmflush等后台回写进程运行，将一定缓存的脏页异步地刷入外存)；
vm.dirty_ratio = 20 当文件系统缓存脏页数量达到系统内存百分之多少时（如10%），系统不得不开始处理缓存脏页（因为此时脏页数量已经比较多，为了避免数据丢失需要将一定脏页刷入外存）；在此过程中很多应用进程可能会因为系统转而处理文件IO而阻塞;。

3）messages日志存在非常多python 报错脚本，会导致进程数快速增加。

4）CCSE集群IO压力不均衡，Master节点除了承载集群管理压力还要承载业务压力。

优化建议

4.1 写缓存触发问题通常出现在大内存的主机，调整内核参数

vm.dirty_ratio 由 20% 修改为10%；
vm.dirty_background_ratio 由10% 修改为5%。

4.2 CCSE集群,Master与node节点未作分离的情况下,应该考虑业务的类型,报表分析和高并发类业务尽量在NODE节点

4.3 协调xxxd厂商对python脚本优化，处理脚本报错,减少IO处理

4.4 在目前未找到对应应用厂家的情况，梳理当前应用厂商，看对应的业务写流量情况，以便后续调度到NODE节点

4.5 增加脏缓存使用率的监控，达到85%告警，以便提前处理问题

END

本文作者：唐田寿(上海新炬中北团队）

本文来源：“IT那活儿”公众号

文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。