• DevOps

  • jenkins持续构建中maven-agent的内存消耗多少呢？

gfppower

只有 runtime 是在 maven（用完即销毁） ，其他在 jenkins 目录下（具有持久化）

      shaowenchen jenkins
      我们目前的持续集成没有设置持久化时间，所有的构建成果都推送到私服了。目前观察jenkins构建日志中，基于maven打包命令的执行时间与本地执行时间略高，但可以接受，比较难以忍受的是jenkins切换stage时需要耗时很高，并且在使用echo或者print脚本命令时候也需较长时间。关于这个问题需要调整哪里呢？

          shaowenchen 刚才给你截图的确实是刷新很快造成的，一般出现这个问题也会有超时的情况。

            gfppower

            因为不同的 stage 可以运行不同的运行时，我想切换运行时容器会消耗一定时间。如果可以的话，简单操作直接用默认容器就可以。

            我这边执行简单命令还行。如果方便的话，贴一下脱敏的Jenkinsfile，可能有助于帮你优化一下

                shaowenchen 非常感谢，脱敏处理需要一些时间，您可以将您目前的测试用的jenkinsfile给我一份吗？我试一下看看效果。

                  shaowenchen
                  我在持续集成服务中通过jenkinsfile构建了一个新的持续集成项目。

                  jenkinsfile如下：

                  pipeline {
                  agent {
                  node {
                  label ‘maven’
                  }

                  }
                  stages {
                  stage(‘echo’) {
                  steps {
                  echo ‘hello’
                  }
                  }
                  stage(‘print’) {
                  steps {
                  script {
                  print “hello”
                  }

                    }
}

                  }
                  }

                  系统运行后结果如下：

                  切换stage消耗了太多时间

                    shaowenchen 根据前一个记录我对jenkinsfile进行了调整，在第一个stage中执行script，
                    jenkinsfile如下：

                    pipeline {
  agent {
    node {
      label 'maven'
    }

  }
  stages {
    stage('echo') {
      steps {
        echo 'hello'
        
        script {
          print "hello"
        }
      }
      
    }
    stage('print') {
      steps {
        script {
          print "hello"
        }
      }
    }
  }
}

                    其他不变，耗时情况如下


                    单纯的echo和print就已经达到2秒以上，感觉速度不尽人意。急需要对jenkins执行指令的速度进行加速。另外切换stage所带来的时间开销如何进行优化，毕竟写脚本的时候不希望眉毛胡子都放在一个坑位里。

                      shaowenchen 修改node的label为base如下：

                      pipeline {
  agent {
    node {
      label 'base'
    }
  }
  stages {
    stage('echo') {
      steps {
        echo 'hello'
        script {
          print "hello"
        }
      }
      
    }
    stage('print') {
      steps {
        script {
          print "hello"
        }
      }
    }
  }
}

                      持续集成构建时间如下：

                      发现使用base的响应速度依然没有什么明显提升

                        shaowenchen 目前系统内采用了比较多的groovy脚本，每个脚本命令都执行时间超过了30秒钟 ，要么就是砍脚本内执行的命令行数，要么就是执行手动打包控制，当然最优解依然是jenkins性能优化。毕竟手动打包发布会出问题。

                            gfppower

                            我在3个节点的集群上，用你的例子，执行挺快的。

                            在构建时，去Jenkins 后台看看构建 console 的实时输出，观察一下哪里卡住了。检查一下集群的资源配置是否充足，有没有安全或保护性的限制。

                                shaowenchen 感谢回复，请问执行脚本是在ks-jenkins里还是agent里呀，例如我写的这个，并没有steps中带container (‘maven’),那么它是不是就是在ks-jenkins里执行的呢？

                                  shaowenchen 请教一下我的jenkins不知道具体什么原因在邀请成员到该工程，报错

                                  返回为：
                                  recover from panic situation

                                  可以推测一下什么原因吗？

                                    已经发现主要原因是我们的集群的外部挂载存储影响了速度，使用宿主机磁盘后打包速度很快，

                                    shaowenchen 请教一下，持续集成服务用户丢失该怎么处理，删除成员也失败，

                                    返回：
                                    recover from panic situation

                                      shaowenchen 请教一下在jenkins日志中发现

                                      No valid crumb was included in request for /job/project-MmqA4D4q8ARw/ajaxExecutors by admin. Returning 403.
                                      怎么修复呢？

                                      • Jeff 回复了此帖

                                          gfppower 看下ks-apiserver的日志，里面应该有上面api调用失败的日志

                                              Jeff 我使用的版本是2.1.1的 只有ks-jenkins服务，该怎么看呢？

                                              • Jeff 回复了此帖