Recommended Server Hardware Configurations

SUMMARY

Recommended CPU, memory, disk and network configurations for running the Perforce Server

DETAILS

CPU

The Perforce Server does not use up very much of your CPU resources. Available memory and disk performance are more likely bottlenecks. Despite this, CPU is still an important factor. Adequate CPU power is needed to minimize the blocking potential of large or complex operations.

The Perforce Server employs a forking model (or threading model on Windows); each command is executed in its own process or thread. It is therefore desirable to have multiple CPUs so that concurrent commands can be spread out across the available CPUs. However, it is also important not to neglect the speed of individual CPUs in multi-CPU deployments. Expensive commands can be limited by a single processor and this can lead to lock contention and reduced responsiveness.

Memory

Server performance is highly dependent upon having sufficient memory. We suggest the following formula to approximate your server's memory requirements. This calculation is a conservative estimate and does not take usage patterns into account. It will not satisfy performance expectations in all cases.

		NUMBER OF FILES
x		1.5 KB
=	ESTIMATED MEMORY REQUIREMENTS

Two bottlenecks are relevant in memory utilization. The first bottleneck can be avoided by ensuring that the server does not page when it runs large queries, and the second by ensuring that the db.rev table (or at least as much of it as practical) can be cached in main memory:

• Determining memory requirements for large queries is fairly straightforward: the server requires about 1 kilobyte of RAM per file to avoid paging; 10,000 files will require 10 MB of RAM and so on.
  
  
• To cache db.rev, the size of the db.rev file in an existing installation can be observed and used as an estimate. New installations of Perforce can expect db.rev to require about 150-200 bytes per revision, and roughly three revisions per file, or about 0.5 kilobytes of RAM per file.

Thus, if there are 1.5 kilobytes of RAM available per file, or 150 MB for 100,000 files, the server does not page, even when performing operations involving all files. It is still possible that multiple large operations can be performed simultaneously and thus require more memory to avoid paging. On the other hand, the vast majority of operations involve only a small subset of files.

For most installations, a system with 1.5 kilobytes of RAM per file in the depot suffices.

Please note: The Windows 32-bit platform (including Windows 2000 and 32 bit versions of Windows 2003 and XP) has a 2GB per-process memory utilization limit. On Windows, the Perforce Server runs as a single process, servicing each client request as a thread within that process. For sites with a very large transaction volume, this 2GB limitation can inhibit performance and large operations. The Windows 64-bit platform does not have this memory limitation. The use of a 64-bit version of Windows is preferable for sites that might encounter the 2GB per process limitation of the 32-bit version.

Disk Performance

The Perforce Server is careful when it comes to disk I/O: its metadata is keyed well and accesses are mostly sequential scans of limited subsets of the data.

The only really disk intensive activity is file check-in, when the Perforce Server must write and rename files in the archive. The performance of this operation is heavily dependent on the operating system's filesystem implementation, and in particular whether directory updates are synchronous.

While we do not want to recommend a specific filesystem, in our experience Linux is the fastest because it has asynchronous directory updates, but might have poor recovery if power is cut at the wrong time. The BSD filesystem (also used by Solaris) is slow but is much more reliable. Window's NTFS filesystem is somewhere in between. Perhaps the best combination are filesystems used by IRIX and OSF which are both fast and reliable.

Disk Space

Disk space usage needs to be judged based on three factors: 1) the client files, 2) the Perforce Server meta-database, 3) the Perforce Server file archive. All three factors are entirely dependent on your data and how heavily you use Perforce.

The client file space is simply the size of the files that you need in your client workspace at any one time.

The Perforce Server meta-database's size can be calculated with fair detail, but as a rough estimate it will be 0.5KB per user/per file. That is, if you have 10,000 files and 50 users, you will need about 250MB of disk for the meta-database. This space can grow over time as the histories of individual files get long.

The Perforce Server file archive's size depends on the size of the original files stored, plus more as revisions are added. Approximately 3 times the size of the original files is a comfortable estimate that leaves room to grow.

Network

Perforce can run over any network. So far, there have been no network limitations. Presumably FDDI (Fiber Distributed Data Interface) would be better than 10Mb/sec Ethernet, but some reports mention that using a T1 (1Mb/sec) connection is just like running Perforce locally.

Virtual Machines

The Perforce resource requirements for a virtual machine are the same as a physical machine. However, the virtual machine itself usually requires substantial additional memory and other resources. Running the Perforce Server on a virtual machine (VM) is not recommended for any installation where performance is a premium. Perforce internal tests have shown a 10 to 1 performance loss when running Perforce on a VM. Also, depending on your VM software, there might be additional stability concerns.

Notes:
For more information on specific deployments strategies, please see a selection of Customer Case Studies and past conference papers.