V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
L0L
V2EX  ›  程序员

[讨论及求助] 容器化下的 cpu 调度问题

  •  
  •   L0L · 2024-10-02 22:19:24 +08:00 · 2302 次点击
    这是一个创建于 431 天前的主题,其中的信息可能已经有所发展或是发生改变。
    [背景说明 1 ] 采用某为的硬件设配上搭建的 k8s 集群,部署 java 镜像应用,传统的 spring cloud 全家桶;

    [背景说明 2 ] 进行压力测试,整体上负载不高的情况下,运行正常(监控整体 cpu 压力在 10%左右);

    [奇怪的现象] 尝试给正在运行的服务,每 5 分钟执行 1-2 秒的 cpu 密集型任务时(单线程执行浮点数乘法运算),这时,正在执行的压力测试结果会有明显的 tps 下降现象,监控中 cpu 上升 1%-2%。

    [疑惑] 整体上 pod 的压力并不是很大,为何稍微执行一下任务,测试结果会出现如此大的波动呢?
    16 条回复    2024-10-05 21:25:33 +08:00
    yyzh
        1
    yyzh  
       2024-10-03 00:01:24 +08:00 via Android
    啥处理器?鲲鹏?
    cooltechbs
        2
    cooltechbs  
       2024-10-03 05:40:35 +08:00 via Android
    TPS 下降幅度多大?这个压测看起来不是压的 CPU ,那是不是它的负载分散在所有 CPU 核心上,然后一个单线程被占用的时候,相应核心执行压测任务变慢,导致总体的 TPS 下降?
    fallshuang
        3
    fallshuang  
       2024-10-03 10:03:47 +08:00
    可能是 L3 cache 导致的问题, 建议咨询下 原厂的技术支持,问他们如何 profile L3 cache
    fallshuang
        4
    fallshuang  
       2024-10-03 10:09:58 +08:00
    一个 单路多核 服务器, 如果其中一个核心执行 cpu 密集型运算,会影响到其他核心, 我的第一反应就是 L3 cache 或者相关的通讯 有问题。L3 cache 要做好,的确不容易。
    L0L
        5
    L0L  
    OP
       2024-10-03 10:13:42 +08:00
    @yyzh 对,最新的鲲鹏 920
    L0L
        6
    L0L  
    OP
       2024-10-03 10:18:27 +08:00
    @cooltechbs 压测本身是分散所有压力的;物理机上层是虚拟;虚拟上层又是容器化的集群;跟踪慢的场景情况,随时都有可能,并不在特定的位置,场景本身是 IO 密集型的(多次交互数据库),但数据库响应稳如老狗;这个 cpu 计算任务,是怀疑 cpu 问题后加上的,结果下降异常严重。
    L0L
        7
    L0L  
    OP
       2024-10-03 10:22:56 +08:00
    @fallshuang 本身是 java boy ,确实不知道如何排查了(没有任何权限接触到服务器上了,只有容器内的权限),大佬有办法能从这种权限的基础上,进行更进一步的定位吗?
    choury
        8
    choury  
       2024-10-03 11:36:59 +08:00 via Android
    我印象里 920 是没有超线程的,所以看下 kubelet 有没有开 cpumanager, pod 是否是 Guaranteed 的
    zizon
        9
    zizon  
       2024-10-03 12:03:55 +08:00
    印象中虚拟化需要有 IO 等外部操作/中断的时候才比较好的产生切换.
    纯 CPU 计算似乎没有什么切换的时机.
    L0L
        10
    L0L  
    OP
       2024-10-03 13:03:12 +08:00
    @choury 是的,920 是没有超线程的,一核一线程
    L0L
        11
    L0L  
    OP
       2024-10-03 13:33:19 +08:00
    @zizon 这个确实不太明确,也可能是物理机直接搭建容器化集群;但这个有一个矛盾点,就是实际目前整个物理机的压力负载还比较均匀,没有超用多少 cpu ,测试的时间,机器完全没有其他用途,单纯承载测试压力的机器,不应该产生很频繁的线程切换才对。
    fallshuang
        12
    fallshuang  
       2024-10-04 01:34:18 +08:00
    @L0L 其实,华为应该感谢你们做小白鼠帮忙测试鲲鹏。 你直接找华为的技术支持吧,这个是他们份内的工作
    fallshuang
        13
    fallshuang  
       2024-10-04 01:35:38 +08:00
    @L0L 什么 java boy 啊, 你一辈子只能肏一个女人吗? 那为啥一辈子都是 java boy 呢?
    L0L
        14
    L0L  
    OP
       2024-10-04 12:09:21 +08:00 via Android
    @fallshuang 中肯,走多条路起来,🉑

    回到问题上,假期回来协调华为的来了。牛马是真无奈。
    R4rvZ6agNVWr56V0
        15
    R4rvZ6agNVWr56V0  
       2024-10-05 12:29:41 +08:00
    是不是遇到了 CPU Throttling

    在 Kubernetes 中,当一个 Pod 的 CPU 使用率超过其请求的 CPU 资源时,Kubernetes 会对其进行限制,以确保其他 Pod 也能获得足够的 CPU 资源。

    即使你的整体 CPU 使用率不高,但当 CPU 密集型任务启动时,很可能会导致 Spring Cloud 服务的 CPU 被限流,影响其性能。

    执行看一下:kubectl top 、kubectl describe pod <pod-name>
    L0L
        16
    L0L  
    OP
       2024-10-05 21:25:33 +08:00 via Android
    @GeekGao 确实考虑过,但我减少了瞬时的服务请求,并且在服务端将瞬时的压力请求做了一个队列,有效果,但依然有下降,所以可能还有其他的问题。
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   5176 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 09:16 · PVG 17:16 · LAX 01:16 · JFK 04:16
    ♥ Do have faith in what you're doing.