在对 openEuler 工程进行构建优化以及日常版本构建过程中,发现某些时间某些工程 finished 数量较大(从几十到一千多)或者数量持续较长时间没有变化。
OBS 系统关于 finished 状态的描述:
finished: The package has been built and signed, but has not yet been picked up by the scheduler. This is an intermediate state prior to 'succeeded' or 'failed'.
从上述描述可以推测,finished 的包已经构建并签名完毕了,需要 scheduler 服务进一步处理,scheduler 服务没有及时处理导致 finished 状态的包堆积。
以下通过对多个 OBS 工程构建过程中各个状态的数量进行采集统计(每分钟采集一次),从两个不同的角度,说明 finished 状态的包对工程构建时长的影响:
从折线图可以看到构建过程中 finished 的数量持续较高、时间持续较长,每个finished 曲线下降的点也是 building 曲线上升的点(下图红色方框标志的位置),由此推断 finished 的包阻塞了其它包开始 building。
如果 finished 的包能及时处理,finished 的数量尽早降下来,那么 building 曲线上升的点也会前移,很多包可以尽快开始构建,构建完成的时间也会相应提前。
以 openEuler:20.03:LTS:SP2:Epol x86_64 10:00 ~ 12:00 时间段构建情况为例,有78 个采集点 building 为 0,但 finished 不为0,近似估计 120 分钟内大概有 78 分钟工程在等待某些包finished 状态结束,才能继续其它包构建。
从以上2点可以看出,如果能加快处理 finished 状态包的速度,很多包的构建也可以提前开始,从而缩短工程构建的时间。
从 OBS 文档了解,OBS scheduler 服务除了处理构建完成的包(finished 状态),大部分责任是在计算哪些工程、哪些包需要构建、以什么顺序构建,当前 OBS 所有公共工程,都由单一的 scheduler 服务在处理。随着工程数量以及包数量逐渐增加,scheduler 服务的压力会越来越大,从之前 atop 工具监控看到scheduler 是一个单线程的服务,并且 CPU 占用持续处于 100%,由此推断 scheduler 服务已经成为当前工程构建的性能瓶颈。
根据 OBS 文档以及借鉴 https://build.opensuse.org 部署情况,解决方法可能是扩容 OBS 后台服务节点(OBS 称为 partitioning),分担当前的部分工程及软件包工作,从而缓解性能瓶颈。
该问题影响构建优化的效果,也影响当前日常版本构建需要等待的时间。
如果确定是 obs_sched 性能瓶颈,可以增加一个 partitioning,根据 host-172-16-1-95 节点资源使用情况,建议配置如下
Hey chenyanpanHW, Welcome to openEuler Community.
All of the projects in openEuler Community are maintained by @openeuler-ci-bot.
That means the developers can comment below every pull request or issue to trigger Bot Commands.
Please follow instructions at https://gitee.com/openeuler/community/blob/master/en/sig-infrastructure/command.md to find the details.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。
登录 后才可以发表评论