Planning Your Perforce Server Installation
Select appropriate data storage for your Perforce installation. Create a backup process. Consider the implications of platform selection and the use of anti-virus software. Find additional assistance for Perforce administration issues.
To ensure that you obtain optimum performance and keep your server data safe, use the following guidelines to plan your Perforce server installation.
Essentials of Server Configuration
- Put metadata files (db.*) and the journal file on separate directly attached storage (DAS), preferably on different controllers, to ensure optimal speed.
- Put metadata files and journal files on different disks to ensure that you don't lose them both if a disk fails.
- Put versioned files on direct attached storage to ensure optimal speed.
- Create checkpoints frequently, and back up checkpoints, journal files, and versioned files on a frequent and regular basis.
Choosing Locations for Server Files
To optimize server performance and data integrity, use the following guidelines for file locations. There are three different sets of files for which you need to choose locations:
- Metadata files
- Journal files
- Versioned files
The following table rates server storage options:
By default the Perforce metadata, journal file, and versioned files reside under the Perforce server root (the install directory). You can override the install location for the metadata and journal file when you install the server or later by moving files and setting environment variables. Information on setting these values can be found in our Perforce Command Reference on environment variables.
The versioned file location is determined by the depot Map field in the depot spec and can only be set after installing Perforce. For details on setting the depot Map field, please see our Perforce Command Reference on the p4 depot command.
The metadata files compose the Perforce database, and have names that start with "db."
Place your metadata files on directly attached storage (DAS). There are numerous I/O reads and writes to db files and, for most configurations, best performance comes from having metadata files reside on DAS. It is suggested that you avoid placing metadata files on network attached storage (NAS). Minimizing latency for Perforce metadata I/O improves performance; some NAS implementations have unacceptably high latency characteristics. An intermediate solution involves using a storage area network (SAN), which appears to the server machine as a local device using either FCP or iSCSI. Due to latency introduced by FCP or iSCSI, SAN performance will not be as good as DAS performance for metadata storage.
The journal file is a record of all transactions performed by the server after the last checkpoint was created.
The journal file is of critical importance during restore procedures. For this reason, place your journal file on separate DAS from the metadata files. This device must have excellent write performance. Write operations to the journal can be intensive; therefore, several RAID configurations, such as RAID 5, are not appropriate for the journal. If the disk containing the metadata becomes bad, having the journal on a separate DAS makes it easy to restore your server.
Versioned files store your file revisions.
For best performance, place the versioned files on directly attached storage. While it is possible to place versioned files on network attached storage, performance will suffer during some operations. Considerable hardware resources and system administration are required to achieve good performance when versioned files are located on NAS. For best results with minimum expense and overhead, use a DAS device.
For convenience, large scale deployments might consider SAN and NAS solutions. Although placing the versioned files on DAS will deliver optimal performance, SAN and NAS solutions typically provide greater availability, scalability and manageability.
Planning for Disk Space Consumption
Make sure you install server files on file systems that can accommodate their growth. To further conserve disk space, compress checkpoints and journal files using the "-z" option.
For details, refer to the discussion of performance tuning in the Perforce System Administrator's Guide.
Planning Checkpoints and Backups
Perforce backs up its metadata in files called checkpoints. A checkpoint is a snapshot of your Perforce metadata. However, checkpoints do not include versioned files. When a checkpoint is created, the journal is truncated and an empty journal is created. Checkpoints should be created on a regular basis. The frequency of checkpoints depends on a number of variables, including server usage and server availability. Lightly used servers may only need one checkpoint per month, while mid to large size servers should have checkpoints created once per week, if possible.
Back up all checkpoints, journal files, and versioned files regularly, using your preferred back up application. Maintain access to a one-month backlog of journal files and checkpoints.
Do not back up your metadata files directly! Back up software often locks files. Locking the metadata files can interfere with normal Perforce operation. All of the information in the metadata files is preserved every time you create a checkpoint. It is vital to create complete back ups on a regular basis. Back up the server frequently, to ensure that, in the event of problems that cause server downtime, you can recover quickly and without loss of data.
Anti-virus software can lock metadata files and thereby interfere with normal Perforce operation. Also anti-virus software can degrade server performance by competing for system resources. If anti-virus software must be used on the server machine, ensure that it is set up to exclude the scanning of metadata files and live scan operations.
Using anti-virus software on client machines is preferable to running anti-virus software on the server machine.
Windows Version Limitations
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.
For more platform specific notes please consult Miscellaneous OS idiosyncrasies that affect Perforce.
For More Help
Please see the Perforce System Administrator's Guide for more in-depth explanations of the preceding topics. You can also contact Perforce Technical Support by phone and email (firstname.lastname@example.org). Please take advantage of your support for any questions or concerns you have.