我们有几个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]
答案 0 :(得分：0)
是。 在从站和主站之间传输大量数据导致性能问题确实如此。这适用于存储构建工件以及大量控制台输出。
对于控制台输出，如果您使用timestamper plugin ，性能损失会特别大。如果您的工作已启用，请尝试先禁用该作业。
否则，我通常会避免大量的控制台输出。尝试将控制台输出限制为非常高的作业级别信息（如果发生故障）提供了进一步的＆＃34; secondary＆＃34;日志文件数据。
使用I / O重定向（正如您所做的那样）是实现这一目标的正确方法，例如
mycommand 2>mycommand.stderr.txt 1>mycommand.stdout.txt
这将始终工作（除了非常特殊情况，您可能需要选择特定于命令的选项来重定向命令显式创建的控制台输出流自己的）。