Jenkins性能调优

1. Jenkins Master Configuration

插件数量 插件会导致构建(因为hook)和UI(插件会添加界面元素到UI中)加载时的性能问题,不要添加过多的插件,一定要充分评估插件后再安装。

2.Job数量

当单个Master job数量达到1000+时 UI访问会开始有延迟 这时可以选择增加Jenkins Master数量来提升瓶颈,但是增加Jenkins Master等于拆分jenkins任务,目前还没有多Master Jenkins集群,近期未来预计也不会有。所以在不定制Jenkins的情况下,唯一能够实现负载在Master之间共享的,只能是搭建多个Master,分别支持不同的Job。

3.禁止在Master上运行Job

Master上不应该运行Job,或者只能运行对Jenkins管理至关重要的内部轻量级任务(Jenkins备份、Job清理等),绝对不能运行业务Job。
减少在Master上轮询SCM 针对Git或者Perforce的SCM轮询需要为每个Job的每次轮询运行CLI程序。如果想要可靠的轮询,则应该运行在Master上,不建议在Slave上轮询,因为Slave是不可靠的。 建议使用push hooks代替轮询。
Git可以在大多情况下使用Gerrit Trigger的“Refupdate”事件来代替SCM轮询,针对Perforce,可以将轮询时间间隔设置的长一些。
至于Subversion则使用的是SVNkit而不是CLI程序,所以其不受影响。

4.磁盘IO性能

  • 为Job配置(启动时)和Build记录(延迟加载)使用更快的磁盘,Master采用SSD会很有帮助,分离配置、BUild记录、构件存储。可插拔的构件转移和存储会值得研究(JENKINS-17236)。
  • 使用外部API/UI作为Jenkins前端。
  • Jenkins并不擅长UI性能,UI插件会导致UI性能变的更糟。外部的UI面板或前端系统可以作为替代方案,引发性能问题的插件:Dashboard view plugin 会引发延迟加载问题 Nested View plugin会引发多次针对每个Job的权限重复认证问题,使用正则表达式过滤Job会变的更糟。可以尝试使用明确的Job list,而不是正则表达式。可以使用 Cloudbees Folders Plugin 代替,这个插件可能有效,但是需要评估。
  • HTTP缓存 使用快速的HTTP代理以缓存静态数据可以帮助提升性能,但是需要进一步平涂
    使用Nginx除了代理端口转发之外,还可以缓存静态文件,比如图片、CSS等,即动静分离,是Web应用的常见方法 Servlet容器。

5.Jenkins Slave Configuration

5.1 Slave数量

Jenkins开发团队与一个目标叫“X1K initiative”,即保证Jenkins Master能支持所有Slave共1000个执行器的平滑运行,到目前为止,这依然是一个挑战。有时候当Slave在250台左右出现大量Slave连接在构建过程中中断的情况。有证据显示当Slave过百时,Jenkins会出现Slave连接丢失的情况。因为在Jenkins core 1.521和SSH Slave Plugin 0.27中针对Jenkins remoting做的线程使用改进不应该出现这样的问题,但是并没有得到证实。

5.2 单个Slave的执行器数量

超过Slave容量的情况下,增加执行器数量会因为崩溃、IO阻塞、RAM交换导致整体的吞吐量下降,合理配置 RAM, CPU cores and build 类型。关于RAM的配置,Slave的maximum memory setting配置需要能够支持最大了的Build。CPU应该足够使用,不会达到100%使用率。考虑IO时,IO会释放一些CPU时间,针对单线程的Build,每个CPU核心配置应少于1个执行器。考虑到IOPS限制,为了避免磁盘IO成为瓶颈,一般情况下,如果15分钟内,平均负载超过了CPU核心数量,则执行器数量应该降低。建议,每个Slave配置1个执行器以便实现隔离。基于云的Slave可以很方便的实现隔离,如果是基于专用硬件,可以通过轻量级容器实现同样的隔离。

6.workspace清理

定时清理Workspace 设置构建过期时间 清理老的构建任务 释放磁盘空间,job有时单个任务空间达到几个G也是导致jenkins加载缓慢

7. JVM性能优化

JENKINS_JAVA_OPTIONS=”-Djava.awt.headless=true -Xms10240m -Xmx10240m -XX:MaxNewSize=1024m -XX:MaxPermSize=1024m”

  1. -Xmx:表示java虚拟机堆区内存可被分配的最大上限,通常为操作系统可用内存的1/4大小
  2. -Xms:初始堆大小,表示java虚拟机堆区内存初始内存分配的大小,通常为操作系统可用内存的1/64大小即可,但仍需按照实际情况进行分配

开发过程中,通常会将-Xms 与-Xmx两个参数的配置相同的值,其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小而浪费资源。

  1. -XX:newSize:表示新生代初始内存的大小,应该小于-Xms的值;
  2. -Xmn:至于这个参数则是对 -XX:newSize、-XX:MaxnewSize两个参数的同时配置,也就是说如果通过-Xmn来配置新生代的内存大小,那么-XX:newSize = -XX:MaxnewSize = -Xmn,虽然会很方便,但需要注意的是这个参数是在JDK1.4版本以后才使用的
  3. -XX:PermSize:表示非堆区初始内存分配大小(方法区)
  4. -XX:MaxPermSize:表示对非堆区分配的内存的最大上限(方法区)

最大堆内存与最大非堆内存的和绝对不能够超出操作系统的可用内存


-Xms: 使用的最小堆内存大小
-Xmx: 使用的最大堆内存大小
-XX:PermSize: 内存的永久保存区域大小
-XX:MaxPermSize: 最大内存的永久保存区域大小
这几个参数也不是配置越大越好,具体要根据所在机器实际内存和使用大小配置。

  1. 设置全局属性
    适当设置全局属性,可以避免在 Job 中重复写一些固定值,例如输出日志地址、接口请求地址等等,而且当固定值需要修改时,只需要修改一次即可,不用去每个 Job 里面修改,方便维护

  2. 构建超时时间
    有些 Job 在执行构建时,由于某些原因导致构建挂起,耗时比较长,而这些长时间挂起的 Job 会导致 Jenkins 内存占用比较大,性能下降,严重的会直接导致 Jenkins 挂掉。所以,我们需要设置构建超时时间来预防这种事情发生,一旦超过一定的时间,要让 Job 自动停止掉

原文地址:https://www.cnblogs.com/lemanlai/p/14163937.html