单服务器部署Azure DevOps Server时大量使用自动化流水线为何会出现性能问题

• 全角色资源抢占
  单节点部署时，Azure DevOps Server的应用层服务（API、Web前端、调度服务）、数据层（SQL Server实例）、流水线执行代理（Agent）全部共享同一台机器的CPU、内存、磁盘IO资源。执行自动化构建、测试、发布作业时，Agent进程需要消耗大量资源拉取代码、执行编译、运行测试用例、打包工件，同时SQL Server需要持续写入流水线运行日志、测试结果、元数据信息，应用层还要处理作业状态同步请求，三类进程同时争抢资源时很容易出现硬件资源打满的情况，作业排队等待时间会大幅上升。如果使用机械磁盘作为存储，多进程随机读写会直接将IO带宽占满，是最常见的性能瓶颈点。
• 作业资源无隔离限制
  单节点部署默认没有资源隔离策略，单个重型流水线作业（比如大型前端项目构建、镜像打包、全量自动化测试执行）可能直接占用80%以上的CPU和内存资源，导致后续所有作业、甚至Azure DevOps本身的页面访问、API请求都无法分配到足够资源而超时。不少用户为了提升并发能力会在单节点上部署多个Agent，反而会进一步加剧资源竞争，导致整体性能更差。
• 数据层压力无分流
  SQL Server本身对内存、磁盘IO的要求很高，频繁执行CI/CD作业时会产生大量增量数据：单次流水线的运行日志、测试报告、工件索引、执行历史都会持续写入数据库，同时作业状态查询、历史记录拉取的读请求也会打到同一个SQL实例上，没有读写分离架构的支撑下，很容易出现数据库锁等待、慢查询、写入超时的问题，直接导致流水线作业执行卡顿、状态更新延迟。
• 存储IO叠加冲突
  单节点部署时，流水线构建缓存、发布工件默认都会存储在本地磁盘上，频繁的缓存读写、工件上传下载会和SQL数据读写、Agent编译过程的IO请求抢占磁盘带宽，如果流水线需要产出大尺寸的镜像包、安装包、二进制工件，磁盘IO会直接成为整个系统的性能短板。

内容的提问来源于stack exchange，提问作者Amit znaft