詹金斯的工作很慢。是否与 I/O 相关？

Question

我们有几个 jenkins 管道作业需要比我们预期更长的时间才能完成。特定步骤似乎“挂起”了一段毫无根据的时间。在另一个系统上手动运行这些相同的步骤运行速度明显更快。

一个示例作业是使用 Ruby 递归遍历一堆目录并对这些目录中的每个文件执行 shell 命令的步骤。在我们的 Ubuntu 14.04 Jenkins 系统上运行大约需要 50 分钟。在我的桌面 Mac 上运行相同的命令大约需要 10 秒。

我通过在命令提示符下运行 Ruby 命令对 Jenkins 构建器进行了一些实验，结果与 Jenkins 一样慢。我还通过批量处理 Ruby 将运行的每个单独的 shell 命令并将它们放入 shell 脚本以按顺序运行每个 shell 命令，从而从等式中删除了 Ruby。这也花了很长时间。

我已经阅读了一些关于 STDERR 阻塞的帖子，这可能是原因。然后我做了一些实验，将 STDERR 和 STDOUT 重定向到 /dev/null，命令将在大约 20 秒内完成。这正是我所期望的。

我的问题是： 1. 这些执行时间的减慢是否是某些 I/O 阻塞的结果？ 2. 解决此问题的最佳方法是什么？在某些情况下，我可能想要输出，因此重定向到 /dev/null 可能不起作用。我可以进行内核或操作系统级别的更改吗？

在 Ubuntu 14.04 Amazon EC2 实例 R3.Large 上运行。

Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-108-generic x86_64)
ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-linux]

Answer 1

是的。 在从属和主控之间传输大量数据确实会导致性能问题。这适用于存储构建工件以及大量控制台输出。

对于控制台输出，如果使用timestamper plugin，性能损失会特别大。如果为您的作业启用，请先尝试禁用它。

否则，我会通常避免大量控制台输出。尝试将控制台输出限制为非常高的作业级别信息（在失败的情况下）提供指向更多“辅助”日志文件数据的链接。

使用 I/O 重定向（就像您已经做过的那样）是实现该目标的正确方法，例如

mycommand 2>mycommand.stderr.txt 1>mycommand.stdout.txt

这将总是工作（除了非常特殊情况，您可能需要选择特定于命令的选项来重定向命令显式在其上创建的控制台输出流自己）。