最有效方式是直接在config.toml的[[runners]]区块内设置output_limit=16777216（16MB），覆盖默认4MB限制，避免GitLab Runner因日志超限中断作业，该配置支持热加载且无需重启。
直接在 config.toml 中设置 output_limit 是最有效、最快速的解决方式。微服务项目跑单元测试时，动辄输出数万行日志（比如 Jest、JUnit 或 TestNG 的详细报告），极易突破 GitLab Runner 默认的 4MB（4194304 字节）日志缓冲上限，导致作业中断、控制台报 “job’s log exceeded limit”，看似构建失败，实则是日志传输通道被主动切断。
确认当前 output_limit 实际值
GitLab Runner 并不默认显式写出 output_limit，而是采用内置默认值。不同版本略有差异：
- 较新版本（2024 年后主流部署）默认为 4194304 字节（4MB）
- 部分旧文档提到 4096 字节，那是早期误传或指其他层级限制，可忽略
- 运行
gitlab-runner list或查看config.toml文件中是否已存在该字段，若无，则说明使用默认值
修改 config.toml 添加 output_limit
打开 Runner 的配置文件（通常位于 /etc/gitlab-runner/config.toml 或 ~/.gitlab-runner/config.toml），在任意一个 [[runners]] 区块内添加 output_limit 行（注意：必须放在 [[runners]] 内，不能放在全局根区）：
[[runners]] name = "microservice-runner" url = "https://your-gitlab.com/" token = "xxxxxx" executor = "shell" output_limit = 16777216 # 单位：字节 → 此处设为 16MB
- 建议初调值设为 8388608（8MB） 或 16777216（16MB），覆盖绝大多数微服务全量单元测试日志
- 避免设得过大（如 >64MB），否则可能拖慢日志传输、占用过多内存，尤其在高并发场景下
- 该配置支持热加载：保存后无需重启服务，Runner 每 3 秒自动检测并重载配置（GitLab 官方行为，2026 年仍生效）
配合并发与执行器优化更稳妥
单纯调大 output_limit 能治标，但微服务高频提交 + 多模块并行测试时，还需协同调整，防止资源争抢加剧日志缓冲压力：
- 检查
concurrent值是否合理：若设为 1，所有作业串行，单个长日志作业更容易卡住缓冲；建议按机器核数 × 1.5 设置（例如 8 核设为 12） - 优先选用
docker或kubernetes执行器：相比shell，它们天然隔离日志流，缓冲更稳定；若必须用shell，确保系统 ulimit -f 未设过低硬限制 - 可同步增加
limit字段（在[[runners]]内）：限制该 Runner 实例最多处理几个作业，防止单实例过载影响日志调度，例如limit = 4
验证是否生效
改完配置后，触发一次含大量日志的单元测试作业（如 npm test -- --verbose 或 ./gradlew test --info），观察流水线页面：
- 作业不再因 “log exceeded limit” 中断
- 日志可完整滚动到底部，且最后几秒无截断痕迹
- 可在作业详情页右上角点击 “Raw” 查看原始日志长度，确认实际字节数未超新设上限
