• DevOps

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

目前持续集成服务内有约45个左右的多分支持续集成服务，同时构建不多，一般没有或者3个之内。由于打包速度实在是窝工。我查看kubesphere中的监控，
我的这个感觉是不
是太小了，谁能提供一个目前你的消耗是多少呢？由于打包速度已经达到3小时了，实在是不能忍受，想看看通过哪里可以进行加速，本地镜像仓库，maven私服，本地版本管理工具都已经使用了。目前感觉是jenkins在执行构建中单纯输出一个指令就耗时非常大

已经对jenkins的pod及slave进行了响应的扩容。但依然不理想。

gfppower

Maven Agent Pod 占用内存不超过 500M。下面的提示，请求超时，是因为记录太多了吗？

      请教一下影响Jenkins输出是在ks-jenkins还是在maven容器中呢？

        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