系统要求

TeamCity 服务器 可以在任何最新版本的 Windows 、 Linux 或 macOS 上运行。 服务器操作系统的要求在 这里 列出。

我们也建议您回顾一下您计划使用的集成的 要求。 例如，以下功能可能需要或在 TeamCity 服务器 安装在 Windows 下时运行得更好：

• VCS 与 Azure DevOps （TFS）集成

• VCS 与 VSS 的集成

• Windows 域登录（可以在 Linux 下工作，但可能稳定性较低），特别是 NTLM HTTP 验证

• 在服务器上的 NuGet 源（可以在 Linux 下工作，但可能稳定性较差）

• Agent push 推送至 Windows 机器

如果您没有特定的偏好，总的来说，Linux 平台可能更受欢迎。 他们在文件系统操作和维护方面更有效率。 对操作系统的最终决定应取决于您的公司的可用资源和已建立的实践。

服务器的硬件需求取决于服务器负载，而服务器负载在很大程度上取决于您的构建类型和服务器使用模式。 这一部分包含了关于各种硬件相关方面的注释。

服务器的负载取决于：

• 构建配置的数量

• 历史记录中的构建数量

• 每日运行的构建数量

• 构建消耗和产生的数据量（使用的源文件和工件的大小、构建日志的大小、单元测试的数量和输出大小、检查和重复项命中的数量、产生的工件的大小和数量等）

• 配置了清理规则

• 代理数量及其利用率

• 拥有打开 TeamCity 网页的用户数量

• 从 IDE 插件中登录的用户数量

• VCS 根的数量和类型，以及配置的检查更改的间隔。 VCS签出模式也亦相关：服务器签出模式会生成更大的服务器负载。 特定类型的 VCS 也会影响服务器负载，但可以根据原生 VCS 客户端性能进行大致估算。

• TeamCity 每天在所有 VCS 根目录中检测到的更改数量

• TeamCity 处理的仓库的大小

• TeamCity 每日检出的源码总大小

以下硬件配置能够处理多达100个并发运行的构建。 暗示了这台机器只托管 TeamCity 服务器 - 而不是代理或数据库。

• 适用于服务器的现代多核CPU（8核或以上）

• 16 GB 的内存

• 快速网络连接

• 快速且可靠的硬盘驱动器

• 快速外部数据库访问

案例 1

根据我们的经验，如 Intel 3.2 GHz 双核 CPU，Windows 下的 8 GB 内存，1 GB 网络适配器以及单个 HDD 等硬件可以为以下设定提供可接受的性能：

• 60个项目和300个构建配置（其中四分之一正在活跃并定期运行）

• 每天超过300次构建

• 每次构建约产生 2 MB 日志

• 50个构建代理

• 50 位网页用户和 30 位 IDE 用户

• 100 个 VCS 根（主要是使用服务器检出的 Perforce 和 Subversion），平均检查更改间隔为 120 秒

• 每天超过150次更改

• Kotlin DSL 没有被使用

• 数据库（MySQL）正在同一台机器上运行

• TeamCity 服务器进程具有 -Xmx1100m JVM 设置

案例 2

以下配置可以为负载较大的 TeamCity 服务器提供可接受的性能： Intel Xeon E5520 2.2 GHz CPU（4 核，8 线程），Windows Server 2008 R2 x64 下的 16 GB 内存，1 GB 网络适配器，3 HDD RAID1 磁盘（一般情况下一个，一个用于存放构建工件、日志和缓存，另一个用于数据库存储）。 针对以下设置进行了测试：

• 150个项目和1500个构建配置（其中三分之一正在活跃并定期运行）

• 每天超过1500次构建

• 每次构建大约需要 4 MB 的日志

• 100 个构建代理

• 150 位网页用户和 40 位 IDE 用户

• 250个VCS根（主要是Git、Hg、Perforce和使用代理端检出的Subversion），平均检查更改间隔为180秒

• 每天超过1000次变更

• 数据库（MySQL）正在同一台机器上运行

• TeamCity 服务器进程设置了 -Xmx3700m x64 JVM

然而，为了确保能够良好地处理峰值负载，建议使用更强大的硬件。

如果您在虚拟机上安装 TeamCity ，请确保每天运行 清理 ，以删除过时的构建日志和工件并节省磁盘空间。 根据我们的粗略估算， 案例 1 安装可能需要 7 GB 的磁盘空间，而 案例 2 需要 15 GB，前提是空间得到了最佳利用并考虑了所有峰值负载。

对于部署大规模 TeamCity 安装的一般建议是，从考虑潜在硬件升级的合理硬件开始。 您可以逐渐增加服务器的负载（例如，添加更多的项目）同时监控性能统计数据，然后决定是否需要进行硬件或软件的改进。 还有一个 benchmark plugin 可以用来估计当前服务器安装能处理的同时构建的数量。

我们也建议您遵循服务器管理的最佳实践，例如将磁盘碎片整理保持在合理的水平。

如果您需要增加同时运行的构建（代理）的数量，那么请准备按照相同的比例增加 CPU、内存、数据库和 HDD 的访问速度，以达到相同的性能。 如果您增加每天的构建次数，请准备相应地增加磁盘大小。

一个 TeamCity 服务器 实例可以稳定地与 1000+ 的构建代理（同时运行并积极记录构建运行时间数据的 1000 个构建）进行工作。

每个构建产生的服务器负载取决于这个构建的数据量（日志、测试、失败详细信息、检查/重复问题数量等）。 将数据量合理地限制（将大型输出作为构建成果发布，而不是打印到标准输出中，调整检查配置文件以报告最重要的一些检查结果等等）将有助于服务器扩展以处理更多的并行构建。

如果您需要更多的代理/并行构建，我们强烈建议使用 多节点设置 ，并在节点之间分配项目.

我们不断改进 TeamCity 的性能，并与运行大型 TeamCity 安装的组织紧密合作。 这样，我们可以研究性能问题并改进 TeamCity 以处理更大的负载。

这一部分包含了一份关于调整 TeamCity 服务器设置以提高性能的建议清单。 它假设服务器已经 配置为生产环境使用。

• 定期查看 Server Health 报告（包括隐藏的）。

• 使用单独的 反向代理服务器 （例如，NGINX）来处理 HTTPS。

• 使用单独的服务器来管理外部数据库。 监控数据库性能。

• 监控服务器的 CPU 和 I/O 性能。 根据需要增加硬件资源。

• 确保所有具有适当保留策略的项目都配置了 clean-up。 检查 管理 | 清理 以确保定期执行清理。

• 请考虑为 <TeamCity Data Directory>/system/caches 目录确保良好的 I/O 性能：例如，将其移动到单独的本地驱动器。

• 定期 归档 过时的项目。

• 定期审查已安装的非捆绑插件，并删除那些对服务器运行不必要的插件。

• 尽可能考虑使用 代理端检出。

• 确保构建日志占用的空间合理（最多数十兆字节，但最好少于 10 MB）。

• 如果服务器上配置了大量的 VCS 根目录，您可能需要考虑配置 仓库提交钩子 ，以替代轮询变更；或者，将 VCS 轮询间隔 增加到 300 秒或更多。

• 如果服务器被超过1000个用户使用，可以考虑通过增加 UI刷新间隔 来降低后台 UI 请求的频率。

• 当经常超过500个同时运行的构建并记录大量数据时，请考虑切换到一个 多节点设置。

• 如果您有大量项目或构建配置，我们建议您避免使用 默认代理 ，以释放 TeamCity 服务器资源。 TeamCity 管理员可以在 Web UI 的 支持人员 页面上 禁用 默认代理。

TeamCity 代理 可以在任何最新版本的 Windows、Linux 或 macOS 上运行。 代理操作系统的需求已在 此处 列出。

代理 Java 进程必须：

• 能够打开到通过 serverUrl 属性在 buildAgent.properties 文件中配置的服务器 URL 的出站 HTTP 连接（通常是您在浏览器中查看 TeamCity UI 时使用的相同地址）。
  发送到配置 URL 下路径的请求不应受到限制。 另请参见推荐的 反向代理设置。 确保安装在代理或服务器主机上的任何防火墙、网络配置以及代理（如有）都符合这些要求。

• 对以下目录具有完全的权限（读/写/删除）： <Agent Home Directory> （自动代理升级和代理工具支持所必需）， <Agent Work Directory>， <Agent Temp Directory> ，以及代理系统目录（由 workDir， tempDir 和 systemDir 参数在 buildAgent.properties 文件中设定）。

• 能够启动进程（运行构建）。

• 能够在以下父进程退出时（在代理升级过程中使用）启动嵌套进程。

运行代理进程的 Windows 用户必须：

• 能够启动 / 停止服务（以 Windows 服务形式运行，对于代理升级至关重要，也请参阅 此文章）。

• 能够调试程序（需要用于获取进程转储功能）。

• 能够重新启动机器（这是代理重启功能所必需的）。

• 成为 性能监控用户 组的成员（以便能够 监控 作为 Windows 服务 运行的构建代理的性能）。

• 能够作为 Windows 服务运行，仅当代理作为服务运行时（请参阅 此文章）。

关于赋予权限的说明：

要了解如何授予用户必要的权限，请查看 这篇文章。 您可以使用 Microsoft SubInACL 工具来分配管理服务的权限，这是一款使管理员能够直接编辑安全信息的命令行工具。 该工具使用以下语法：

SUBINACL /SERVICE \\MachineName\ServiceName /GRANT=[DomainName]UserName[=Access]

例如，要授予启动/停止权限，您可能需要执行以下命令：

subinacl.exe /service TCBuildAgent /grant=<user login name>=PTO

运行代理进程的 Linux 用户必须能够运行 已关闭 命令（用于在云环境中运行时的代理机器重启和关闭功能）。 如果您正在使用 systemd ，它不应在主进程退出时终止进程（请使用 RemainAfterExit=yes）。 另请参阅： 如何在 Linux 下设置自动启动代理。

每个构建过程都由 TeamCity 代理启动。 它共享环境，并在 TeamCity 代理所使用的操作系统用户下执行。 确保 TeamCity 代理已经相应地被配置。 参阅 已知问题 了解与 Windows 服务限制相关的信息。

代理的硬件需求由它们运行的构建确定。 运行 TeamCity 代理软件需要额外的 CPU 时间（但通常可以忽略，因为与构建过程的 CPU 要求相比，这个需求较小）和额外的内存：大约 500 MB。 所需的磁盘空间对应于代理上运行的构建（源代码检出，下载的工件，构建过程中消耗的磁盘空间；所有这些都是针对常规发生的构建）。

虽然您可以在与 TeamCity 服务器相同的机器上运行构建代理，但推荐的方法是为每个构建代理使用单独的机器（可以是虚拟的）。 如果您选择在 同一台机器上安装多个代理，那么请考虑可能出现的 CPU、硬盘、内存或网络瓶颈。 Performance Monitor 构建功能可以帮助分析实时数据。

如果您考虑为 TeamCity 代理（例如，在 Amazon EC2上）进行云部署，也请参见 这篇文章。

数据库的大小取决于：

• 每天启动了多少次构建

• 构建中报告了多少个测试

• 清理 规则（保留策略）和计划

推荐的初始大小为 4 GB。 当从内部数据库迁移时，我们建议至少将当前内部数据库的大小增加一倍。 例如，JetBrains 内部的 TeamCity 服务器的外部数据库（不包括 redo log 文件）的大小约为 1 TB。 将您的数据库设置为自动增长有助于在必要时将文件大小增加到预定的限制，从而最小化监控磁盘空间的工作。

在大多数情况下，为重做日志（请参阅下表）和撤消文件分配 1 GB 的空间就足够了。

以下因素可能会影响数据库性能：

• 数据库类型（RDBMS）

• 代理数量（并行运行的构建数量）

• 所有用户打开的网页数量

• 清理规则（保留策略）

建议将 TeamCity 数据目录 和数据库数据文件放在物理上不同的硬盘上（即使 TeamCity 服务器和 RDBMS 共享同一个主机）。

建议将重做日志放在单独的物理磁盘上 —— 特别是当有50个或更多的代理时。

各种 RDBMS 的重做日志（或类似实体）命名：

• RDBMS：日志名称

• Oracle：重做日志

• MS SQL Server：事务日志

• PostgreSQL：WAL（预写式日志）

• MySQL + InnoDB 和 Percona：Redo Log

PostgreSQL：建议使用9.2+版本，该版本具有许多查询优化功能。 请查看 PostgreSQL 文档 中关于预写式日志（WAL）的信息。

Oracle：建议保持统计信息——所有自动收集的统计信息应该启用（自 Oracle 10.0 版本以后，这是默认设置）。 请参阅 Oracle 文档 中关于重做日志文件的信息。

MS SQL Server ：强烈建议不要使用 jTDS 驱动程序 —— 它无法与 nchar/nvarchar 一起使用。 为了保留 Unicode 流，这可能会导致查询花费很长时间并消耗许多 I/O 操作。 请查看 Microsoft Knowledge base 上关于重做日志的信息。 如果您使用 jTDS ， 请考虑进行迁移。

MySQL：查询优化器可能效率不高：某些查询可能会得到错误的执行计划，导致它们消耗大量时间和 I/O 操作。