5

在我的构建日志的末尾，我有以下内容：

[15:16:22]: Publishing artifacts (25m:29s)
[15:16:22]: [Publishing artifacts] Paths to publish: [automation/artifacts]
[15:16:23]: [Publishing artifacts] Sending files

我尝试阅读代理日志并得到了这个

[2013-05-02 15:16:23,023]   INFO -    jetbrains.buildServer.AGENT - Start: Sending files 
[2013-05-02 15:41:51,214]   INFO -    jetbrains.buildServer.AGENT - Done publishing artifacts to , total files published: 22

工件的大小 272 MB。在过去，这部分过程不到半分钟。

我在哪里可以找到有关该操作的更多数据？

4

3 回答 3

3

检查主机与 Teamcity 主服务器和 Teamcity 代理之间的网络连接。Teamcity 将所有工件保存在主服务器上，并在构建结束时将它们从代理复制到主服务器。

于 2013-05-16T19:21:33.190 回答
0

服务器上有很多文件吗？我发现在有很多文件的服务器上完成大约需要 50 分钟，但是文件在 5 分钟后已经上传，所以我认为它可能正在尝试列出所有文件或其他内容。当我将工件上传到另一个文件较少的服务器时，它会在大约 5 分钟内发布它

于 2017-02-01T14:26:59.967 回答
0

我喜欢回答这个问题，因为我们最近遇到了这个问题。

我们将 Teamcity 从 v9.1.7 升级到 V2019.2.1，在更新后的 Teamcity 中有新的请求，例如/app/agents/v1/commands/next 增加 Teamcity 的流量。这些类型的请求将始终从 Teamcity 代理轮询到 Teamcity 服务器。

如果您的 Teamcity 服务器位于 Apache 代理之后，请求流程将是这样的。

Client <--> load balancer <--> Apacher <--> Tomcat of Teamcity.

如果在我们的例子中 Apache 无法处理那么多流量，因为由于新的自动请求，现在请求更多地流向 Teamcity，那么在与 Teamcity 的所有交互期间，请求将在 Apache 端排队，从而增加所有请求和丢包的时间。

于 2020-07-19T08:53:44.383 回答