上传项目图片:“Jenkins”必威国际有限公司
  1. 必威国际有限公司
  2. 必威国际有限公司詹金斯- 65308

必威国际有限公司Jenkins.trimLabelsgets increasingly slower as number of nodes and labels increase

    XML 可打印的

    细节

    • 类型: 错误
    • 状态: Closed
      The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">关闭
      查看工作流
    • 优先级: 主要
    • 解决方法: 固定
    • 组件/ s: 核心
    • 环境:
    • 类似的问题:
    • 发布:
      2.288 - 2021年4月13日,2.289 - 2021年4月20日

      描述

      我们一直在试图追踪一些关于队列锁定的问题
      对Jenkins集群的争夺。必威国际有限公司锁争用表现在
      UI不稳定/缓慢和REST API调用失败,添加,更新或
      删除节点。我们在主端和客户端(版本)上使用Swarm插件
      3.24)在代理程序上连接到主程序。REST API失败不是原因
      对于Jenkins的异常,但是对于超出必威国际有限公司配置的API调用
      proxy_read_timeout (180s)用于Jenkins前面的nginx实例。必威国际有限公司
      这体现在接收504的代理的群集客户端进程上
      nginx,因为Jenk必威国际有限公司ins没有及时回复。

      在不稳定期间收集的线程转储显示有数百个
      线程正在等待Queue锁能够添加、更新或删除
      一个节点。

      "处理POST /plugin/swarm/createSlave from 10.224.1.234: Jetty (winstone)-1218487" #1218487 prio=5 os_prio=0 tid=0x00007f4732c7f800 nid=0x2f96 waiting on condition [0x00007f3c6b5f2000] java.lang.Thread.State: waiting (parking) at sun.misc.Unsafe。park(本机方法)-停车等待<0x00007f3f117ca288> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) atjava.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) at hudsonmodel . queue . _withlock (Queue.java:1441) [snip.]

      绝大多数情况下,线程在每次执行时都持有Queue锁
      线程转储在Jenkins中执行操作。必威国际有限公司trimLabels方法为
      添加、更新或删除节点的一部分。

      "处理POST /plugin/swarm/createSlave from 10.240.81.215: Jetty (winstone)-1218362" #1218362 prio=5 os_prio=0 tid=0x00007f47265fd000 nid=0x2e11 runnable [0x00007f3c85ceb000] java.lang.Thread.State:可运行在hudson.util.QuotedStringTokenizer.hasMoreTokens (QuotedStringTokenizer.java: 184) hudson.model.Label.parse (Label.java: 585) hudson.model.Node.getAssignedLabels (Node.java: 303) hudson.model.Label.matches (Label.java: 196) hudson.model.Label.getNodes (Label.java: 233) hudson.model.Label.isEmpty (Label.java: 430) jenkins.model.必威国际有限公司Jenkins.trimLabels (Jenkins.java: 2201) jenkins.model.Nodes调用(jenkins.model.Nodes Nodes.java: 214) 4.美元4.美元(Nodes.java: 210)hudson.model.Queue._withLock (Queue.java: 1443) hudson.model.Queue.withLock (Queue.java: 1304) je必威国际有限公司nkins.model.Nodes.updateNode (Nodes.java: 210) jenkins.model.Jenkins.updateNode (Jenkins.java: 2176) hudson.model.Node.save (Node.java: 139) hudson.model.Node.setTemporaryOfflineCause (Node.java: 274) hudson.model.Computer.setNode (Computer.java: 820) hudson.slaves.SlaveComputer.setNode (SlaveComputer.java: 895) hudson.model.AbstractCIBase.updateComputer (AbstractCIBase.java: 137)hudson.model.AbstractCIBase.access$000(AbstractCIBase.java:43) at hudson.model.AbstractCIBase. java:223) at hudson.model.Queue.withLock(Queue.java: 1384) at hudson.model.Queue.withLock(Queue.java:1261) at hudson.model.AbstractCIBase. updatecomputerlist (AbstractCIBase.java:206) at jenkins.model.Jenk必威国际有限公司ins.updateComputerList(Jenkins.java:1632) at jenkins.model. queue . _withlock (Queue.java:1384) at hudson.model.AbstractCIBase. updatecomputerlist (Jenkins.java:1632) at jenkins.model. model. queue . _withlock (Queue.java:1384) athudson.model.Queue.withLock(Queue.java:1261) at 必威国际有限公司jenkins.model.Nodes.addNode(Nodes.java:147) at jenkins.model.Jenkins.addNode(Jenkins.java:2155) at hudson.plugins.swarm.PluginImpl.doCreateSlave(PluginImpl.java:224)

      属性创建的两个存档文件collectPerformanceData
      包含相关线程转储的脚本。

      在前面提到的不稳定时期有1500-1600年
      唯一的标签和400-500个工作人员,从脚本控制台收集使用
      必威国际有限公司Jenkins.instance.labels.size ()而且必威国际有限公司Jenkins.instance.nodes.size ()

      我可以使用Groovy脚本来复制这种越来越慢的速度
      我们的工人创建步骤是什么样的。我已经附上了两个脚本。
      create-workers.groovy创造工人,remove-workers.groovy删除
      他们。为了使它与我们创建的群集客户端工作流相匹配SwarmSlave代理
      在脚本中,但这个细节可能对复制不重要
      目的。

      创建和删除带有单一标签的worker非常快
      期望。下面是一些用于创建的剪切输出(完整输出附在后面)create-workers-single-label.log):

      ...uniqueLabels: 395 nodes: 393 swarm-test-392: 63ms uniqueLabels: 396 nodes: 394 swarm-test-394: 87ms uniqueLabels: 398 nodes: 396 swarm-test-396: 62ms uniqueLabels: 399 nodes: 397 swarm-test-396: 62ms uniqueLabels: 400 nodes: 398 swarm-test-397: 62ms uniqueLabels: 401 nodes: 399 swarm-test-398: 63ms uniqueLabels: 402 nodes: 400 swarm-test-399: 63ms uniqueLabels: 403 nodes: 401 swarm-test-399: 63ms uniqueLabels: 403 nodes: 401 swarm-test-400: 64ms Total time to create 400 workers: 9183ms

      然后相同的删除(完整的输出附加为remove-workers-single-label.log):

      ...uniqueLabels: 10 nodes: 8 swarm-test-91: 0ms uniqueLabels: 9 nodes: 7 swarm-test-92: 0ms uniqueLabels: 8 nodes: 6 swarm-test-93: 1ms uniqueLabels: 7 nodes: 5 swarm-test-94: 0ms uniqueLabels: 6 nodes: 4 swarm-test-95: 1ms uniqueLabels: 4 nodes: 2 swarm-test-97: 0ms uniqueLabels: 3 nodes: 1 swarm-test-98: 0ms uniqueLabels: 1 nodes: 0 swarm-test-99: 1ms Total time to remove 401 workers: 8675ms

      但一旦你开始添加更多的标签,速度就会急剧下降。
      下面是一些用于创建的剪切输出(完整输出附在后面)create-workers-multiple-labels.log):

      ...uniqueLabels: 811 nodes: 394 swarm-test-393: 1875ms uniqueLabels: 813 nodes: 395 swarm-test-394: 1883ms uniqueLabels: 815 nodes: 396 swarm-test-395: 1888ms uniqueLabels: 817 nodes: 397 swarm-test-396: 1901ms uniqueLabels: 819 nodes: 398 swarm-test-397: 1913ms uniqueLabels: 821 nodes: 399 swarm-test-398: 1915ms uniqueLabels: 823 nodes: 400 swarm-test-399: 1927ms uniqueLabels: 825 nodes: 401 swarm-test-400:创建400个工人的总时间:261866毫秒

      然后相同的删除(完整的输出附加为remove-workers-multiple-labels.log):

      ...uniqueLabels: 39 nodes: 8 swarm-test-91: 3ms uniqueLabels: 37 nodes: 7 swarm-test-92: 2ms uniqueLabels: 35 nodes: 6 swarm-test-93: 2ms uniqueLabels: 33 nodes: 5 swarm-test-94: 1ms uniqueLabels: 31 nodes: 4 swarm-test-95: 1ms uniqueLabels: 29 nodes: 3 swarm-test-96: 0ms uniqueLabels: 27 nodes: 2 swarm-test-97: 0ms uniqueLabels: 25 nodes: 1 swarm-test-98: 1ms uniqueLabels: 1 nodes: 0 swarm-test-99: 0ms Total time to remove 401 workers: 258555ms

      增加(在本例中大约是它的两倍)唯一标签的数量使
      同样的过程,原来每个操作大约需要9秒
      每次操作4分20秒。

      有什么办法吗必威国际有限公司Jenkins.trimLabels更便宜,甚至在
      面对成千上万的标签和成百上千的工人?在我看来就像
      当前代码路径有几个嵌套循环(每个标签上的外循环,
      内循环遍历每个worker,内循环遍历标签中每个解析过的标记
      Tokenizer,对原始标签str中的每个字符进行内部循环,这些都是什么
      当输入变大时,会增加执行时间。

        附件

        1. create-workers.groovy
          1 kB
        2. create-workers-multiple-labels.log
          20 kB
        3. create-workers-single-label.log
          19 kB
        4. performancedata.13272 output.tar.gz——2.
          6.06 MB
        5. performancedata.13272 output.tar.gz——3.
          5.52 MB
        6. remove-workers.groovy
          0.6 kB
        7. remove-workers-multiple-labels.log
          20 kB
        8. remove-workers-single-label.log
          19 kB

          问题的链接

            活动

            隐藏
            raihaanRaihaan Shouhell增加了评论-

            嘿,加文,多亏了你和乔纳,这事能这么快解决。最初的调查做得很好,这让我能够专注于这个问题。这样的合作有助于问题得到快速解决。

            显示
            raihaanRaihaan Shouhell增加了评论-嘿,加文,多亏了你和乔纳,这事能这么快解决。最初的调查做得很好,这让我能够专注于这个问题。这样的合作有助于问题得到快速解决。
            隐藏
            fatmcgav加文·威廉姆斯增加了评论-

            Beatriz穆尼奥斯

            我刚刚注意到这个问题被标记为“2.277.4-拒绝”。

            这意味着它是会成为下一个LTS版本的一部分吗?

            你能详细说明这背后的原因吗?到目前为止,从我们的测试和生产使用情况来看,这个变化对Jenkins的整体性能有巨大的好处,特别是在运行动态创建的数百个连接代理时……必威国际有限公司

            谢谢

            显示
            fatmcgav加文·威廉姆斯增加了评论-嗨,Beatriz Muñoz我刚刚注意到这个问题已被标记为“2.277.4-拒绝”。这是否意味着它不会成为下一个LTS版本的一部分?你能详细说明这背后的原因吗?到目前为止,从我们的测试和生产使用情况来看,这个变化对Jenkins的整体性能有巨大的好处,特别是在运行动态创建的数百个连接代理时……必威国际有限公司谢谢
            隐藏
            raihaanRaihaan Shouhell增加了评论-

            嘿,Gavin,它被拒绝了,因为这个变化没有在每周发布很长时间,它不是一个回归。因此,决定将其排除在外,因为这一变化带来了倒退的风险。所以是的,它不会在2.277.4,它可能会在之后的LTS中,其基线可能是2.289。

            显示
            raihaanRaihaan Shouhell增加了评论-嘿,Gavin,它被拒绝了,因为这个变化没有在每周发布很长时间,它不是一个回归。因此,决定将其排除在外,因为这一变化带来了倒退的风险。所以是的,它不会在2.277.4,它可能会在之后的LTS中,其基线可能是2.289。
            隐藏
            bmunozBeatriz穆尼奥斯增加了评论-

            嘿,加文。雷汉说的是对的。在这里讨论

            显示
            bmunozBeatriz穆尼奥斯增加了评论-嘿,加文。雷汉说的是对的。这里是讨论
            隐藏
            fatmcgav加文·威廉姆斯增加了评论-

            谢谢你提供的细节

            显示
            fatmcgav加文·威廉姆斯增加了评论-谢谢你提供的细节

              受让人:
              raihaanRaihaan Shouhell
              记者:
              jonahbull约拿牛
              投票:
              3. 为这个问题投票
              观察人士:
              9 开始关注这个问题

                日期

                创建:
                更新:
                解决: