我们有几个 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]
最佳答案
是的。 在 slave 和 master 之间传输大量数据确实会导致性能问题。这适用于存储构建工件以及大量控制台输出。
对于控制台输出，如果使用 timestamper plugin，性能损失会特别大。如果为您的工作启用，请先尝试禁用它。
否则，我通常会避免大量的控制台输出。尝试将控制台输出限制为非常高的作业级别信息，这些信息(在失败的情况下)提供指向更多“辅助”日志文件数据的链接。
使用 I/O 重定向(正如您已经做过的那样)是实现该目标的正确方法，例如
mycommand 2>mycommand.stderr.txt 1>mycommand.stdout.txt
这将总是工作(除了非常的特殊情况，您可能需要选择特定于命令的选项来重定向命令在其上显式创建的控制台输出流自己的)。
关于ruby - Jenkins 工作缓慢。 I/O 相关吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42444566/