Hardware Requirements for TeamCity

The hardware requirements differ for the server and the agents.

The agent hardware requirements are basically determined by the builds that are run. Running TeamCity agent software introduces requirement for additional CPU time (but it can usually be neglected comparing to the build process CPU requirements) and additional memory: about 150Mb. Although, you can run build agent on the same machine as the TeamCity server, the recommended approach is to use a separate machine (though, it may be virtual) for each build agent. If you chose to install several agents on the same machine, please consider possible CPU, disk, memory or network bottlenecks that might occur.

The server hardware requirements depend on the server load, which in its turn depends significantly on the type of the builds and server usage. Consider the following general guidelines.

Overview on the TeamCity hardware resources usage :

• CPU: TeamCity utilizes multiple cores of the CPU, so increasing number of cores makes sense. It is probably not necessary to dedicate more then 8 cores to TeamCity server.

• Memory: See a Installing and Configuring the TeamCity Server on memory usage. Consider also that required memory may depend on the JVM used (32 bit or 64 bit). You will probably not need to dedicate more then 4G of memory to TeamCity server.

• HDD/disk usage: This sums up from the temp directory usage (<TeamCity home>/temp and OS temp directory) and .BuildServer/system usage. Performance of the TeamCity server highly depends on the disk system performance. As TeamCity stores large amounts of data under .BuildServer/system (most notably, VCS caches and build results) it is important that the access to the disk is fast. (e.g. please pay attention to this if you plan to store the data directory on a network drive).

• Network: This mainly sums up from the traffic from VCS servers, to clients (web browsers, IDE, etc.) and to/from build agents (send sources, receive build results, logs and artifacts).

The load on the server depends on :

• number of build configurations;

• number of builds in the history;

• number of the builds running daily;

• amount of data generated by the builds (size of the build log, number and output size of unit tests, number of inspections and duplicates hits etc.);

• cleanup rules configured

• number of agents and their utilization percentage;

• number of users having TeamCity web pages open;

• number of users logged in from IDE plugin;

• number and type of VCS roots as well as checking for changes interval for the VCS roots. VCS checkout mode is relevant too: server checkout mode generates greater server load. Specific types of VCS also affect server load, but they can be roughly estimated based on native VCS client performance;

• number of changes detected by TeamCity per day in all the VCS roots;

• total size of the sources checked out by TeamCity daily.

Based on our experience, a modest hardware like 3.2 dual core CPU, 3.2Gb memory under Windows, 1Gb network adapter can provide acceptable performance for the following setup:

• 60 projects and 300 build configurations (with one forth being active and running regularly);

• more then 300 builds a day;

• about 2Mb log per build;

• 50 build agents;

• 50 web users and 30 IDE users;

• 100 VCS roots (mainly Perforce and Subversion using server checkout), average checking for changes interval is 120 seconds;

• more then 150 changes per day;

• the database (MySQL) is running on the same machine, main TeamCity process has -Xmx1100m -XX:MaxPermSize=120m JVM settings.

However, to ensure peak load can be handled well, more powerful hardware is recommended.

HDD free space requirements are mainly determined by the number of builds stored on the server and the artifacts size/build log size in each.

If the builds generate large number of data (artifacts/build log/test data), using fast hard disk for storing .BuildServer/system directory and fast network between agents and server are recommended.

The general recommendation for deploying large-scale TeamCity installation is to start with a reasonable hardware and add more projects to the server gradually, monitoring the performance characteristics and deciding on necessary hardware or software improvements. Anyway, best administration practices are recommended like keeping adequate disk defragmentation level, etc.

If you consider cloud deployment for TeamCity agents (e.g. on Amazon EC2), please also review Setting Up TeamCity for Amazon EC2

A note on agents setup in JetBrains internal TeamCity installation: We use both separate machines each running a single agent and dedicated "servers" running several virtual machines each of them having a single agent installed. Experimenting with the hardware and software we settled on a configuration when each core7i physical machine runs 3 virtual agents, each using a separate hard disk. This stems form the fact that our (mostly Java) builds depend on HDD performance in the first place. But YMMV.