2个工具,助你排查Kubelet CPU 使用率过高问题

本文记录了一次排查Kubernetes集群中Kubelet进程CPU使用率长时间100%的问题。通过strace工具发现futex系统调用异常,尤其是FUTEX_WAIT_PRIVATE超时。进一步使用go pprof分析,定位到*cadvisor.manager.containerData.housekeeping函数的性能瓶颈。问题根源在于内存缓存(slab memory)未及时释放,影响了CGroup状态获取的性能。解决方案包括清理节点缓存和升级内核版本以优化CGroup查询性能。
摘要由CSDN通过智能技术生成

本文是跟安信证券容器云技术团队共同进行问题排查的最佳实践。

问题背景

我们发现客户的Kubernetes集群环境中所有的worker节点的Kubelet进程的CPU使用率长时间占用过高,通过pidstat可以看到CPU使用率高达100%。本文记录下了本次问题排查的过程。

图片

集群环境

在这里插入图片描述

排查过程

使用strace工具对kubelet进程进行跟踪

1、由于Kubelet进程CPU使用率异常,可以使用strace工具对kubelet进程动态跟踪进程的调用情况,首先使用strace -cp 命令统计kubelet进程在某段时间内的每个系统调用的时间、调用和错误情况。

图片

从上图可以看到,执行系统调用过程中,futex抛出了五千多个errors,这并不是一个正常的数量,而且该函数占用的时间达到了99%,所以需要进一步查看kubelet进程相关的调用。

2、由于strace -cp命令只能查看进程的整体调用情况,所以我们可以通过strace -tt -p 命令打印每个系统调用的时间戳,如下:

图片

从strace输出的结果来看,在执行futex相关的系统调用时,有大量的Connect timed out,并返回了-1和ETIMEDOUT的error,所以才会在strace -cp中看到了那么多的error。

futex是一种用户态和内核态混合的同步机制,当futex变量告诉进程有竞争发生时,会执行系统调用去完成相应的处理,例如wait或者wake up,从官方的文档了解到,futex有这么几个参数:

futex(uint32_t *uaddr, int futex_op, uint32_t val,
                 const struct timespec *timeout,   /* or: uint32_t val2 */
                 uint32_t *uaddr2, uint32_t val3);

官方文档给出ETIMEDOUT的解释:

ETIMEDOUT
       The operation in futex_op employed the timeout specified in
       timeout, and the timeout expired before the operation
       completed.

意思就是在指定的timeout时间中,未能完成相应的操作,其中futex_op

  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值