Azure Pipeline代理资源分配查看及Docker测试超时排查咨询

二、CPU核数限制导致测试变慢且CPU使用率低的原因 #

你本地模拟Azure代理2核限制后出现的问题，核心原因如下：

1. .NET测试并行度自动适配核数
   .NET测试默认根据CPU核数设置并行测试数量，核数减少后，并行运行的测试数量随之降低，原本可并行完成的测试变为串行，总耗时拉长。若测试为IO密集型（如频繁调用数据库），单个测试CPU占用率低，但等待IO的时间被放大，整体CPU使用率就会偏低。
   解决办法：手动指定并行数，在项目中添加.runsettings文件：

   <RunSettings>
     <RunConfiguration>
       <MaxCpuCount>2</MaxCpuCount> <!-- 与CPU核数匹配，强制用满资源 -->
     </RunConfiguration>
   </RunSettings>
   

   测试命令添加--settings ./test.runsettings即可生效。

2. Docker CPU限制的调度逻辑
   Docker通过cgroups实现CPU限制，核数受限后，容器的CPU时间片被严格管控。若测试过程存在大量上下文切换（如频繁创建对象、数据库连接），调度器可能无法及时为测试进程分配CPU时间，导致进程处于等待状态，表现为CPU使用率低但耗时增加。

3. 数据库容器的资源抢占
   你的数据库容器未设置CPU限制，当测试容器请求CPU时，数据库容器可能抢占资源，导致测试进程等待数据库响应的时间变长。可给数据库容器添加合理的CPU限制，例如：

   integration_test_db_server:
     # ... 原有配置
     deploy:
       resources:
         limits:
           cpus: '1.0'
           memory: 2gb
   

三、针对现有配置的优化建议 #

1. 给Pipeline添加监控与日志采集 #

修改Pipeline脚本，整合资源监控与日志输出：

steps:
  - script: |
      # 启动Docker stats后台监控
      docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}\t{{.BlockIO}}" > docker_stats.log &
      STATS_PID=$!
      # 构建并启动容器
      docker compose build --no-cache
      docker compose up --abort-on-container-exit
      # 停止监控并打印所有日志
      kill $STATS_PID
      echo "=== Docker资源使用统计 ==="
      cat docker_stats.log
      echo "=== 测试服务日志 ==="
      docker logs test_service || true
      echo "=== 数据库服务日志 ==="
      docker logs db_server || true
    displayName: 'Docker Compose构建启动+资源监控'

2. 调整容器资源与测试并行度 #

• 给测试容器添加CPU限制，与Azure代理的2核匹配：

  test_service:
    # ... 原有配置
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4gb
  

• 添加.runsettings文件强制测试并行数，充分利用2核资源。

3. 优化测试与数据库交互 #

• 测试中复用数据库连接，避免每次测试新建连接；
• 给数据库操作添加超时时间，防止无限等待；
• 测试前执行初始化查询，预热数据库缓存，减少后续查询耗时。

内容的提问来源于stack exchange，提问作者dev.e.loper