Filesystem

File size and disk I/O are the key issues here. For more information, see Filesystems.

Filesystem performance

Helix Core Server is judicious with its use of disk I/O. Helix Core Server metadata is well-keyed, and accesses are mostly sequential scans of limited subsets of the data. The most disk-intensive activity is file check-in, where the Helix Core Server must write and rename files in the archive. Server performance depends heavily on the operating system’s filesystem implementation, and in particular, on whether directory updates are synchronous. Server performance is also highly dependent upon the capabilities of the underlying hardware’s I/O subsystem.

Helix Core Server does not recommend any specific hardware configuration or file system. Linux servers tend to have the best performance because of Linux’s asynchronous directory updating. However, a Linux server might have poor recovery if power is cut at the wrong time.

Performance in systems where database and versioned files are stored on NFS-mounted volumes is typically dependent on the implementation of NFS and the underlying storage hardware. Helix Core Server has been tested and is supported using implementations that support the flock protocol.

Under Linux and FreeBSD, database updates over NFS can be an issue because file locking is relatively slow. If the journal is NFS-mounted on these platforms, all operations will be slower. In general (particularly on Linux and FreeBSD), we recommend that the Helix Core Server database, depot, and journal files be stored on disks that are local to the machine running the Helix Core Server process or that they be stored on a low-latency SAN device.

These issues affect only the Helix Core Server process (p4d). Helix Core Server applications, (such as p4, the Helix Core Server Command-Line Client) have always been able to work with client workspaces on NFS-mounted drives (for instance, workspaces in the users' home directories).

Separate physical drives for server root and journal

The P4ROOT directory contains the metadata database and versioned file Source files stored in the depot, including one or more revisions to each file. Also known as archive files, archives, and depot files. Versioned files typically use the naming convention 'filename,v' or '1.changelist.gz'.s.

Important

We recommend that the P4ROOT directory be on a different physical drive than your journal file because:

If a disk failure corrupts the drive containing P4ROOT, your journal file will not be affected. You can then use the journal file to restore any lost or damaged metadata.
Separating the live journal from the db.* files can improve performance.

Location of server root and the journal

You can set the location for the metadata database and the journal file when you install the server. You can also change the location later by moving files and reconfiguring the server. See the environment variables P4ROOT and P4JOURNAL in the Helix Core Command-Line (P4) Reference.

Location of versioned files

You can set the location of the versioned files after installing Helix Core Server. To set the location for:

all depots, use the server.depot.root configurable

for individual depots, use the Map: form field in the p4 depot spec to specify an absolute location