System requirements

The following are hardware requirements and file-system considerations for installing and running a P4 Server on-premises.

Hardware requirements

Review the following hardware requirements before installing and running P4 Server on-premises.

CPU

CPU usage can increase with features such as compression, lockless reads, or an inefficient protections table. In general, there is a trade-off between clock speed and core count.

Consider one of the following minimum CPU configurations:

  • 2.4 GHz with 8 cores

  • 3.2 GHz with 4 cores

Higher clock speeds can offset fewer cores. For more information, see CPU in the Optimizing P4 Server performance section.

Memory

Use the following guidelines to estimate memory requirements for a single-server deployment:

  • 64 MB per licensed user

  • 1.5 KB of RAM per file in the depot

P4 Server benefits from large amounts of RAM, which the operating system can use for filesystem cache. Reading from cache is significantly faster than disk I/O, even on high-performance storage.

For memory recommendations and performance tuning, see Optimizing P4 Server performance.

Disk space allocation

Disk space usage by P4 Server depends on several factors. For details, see Monitor disk space usage.

Client workspaces

Disk usage reflects the number and size of files users sync to their client workspaces Directories on your machine where you work on file revisions that are managed by P4 Server..

Server metadata database

The metadata Information that P4 Server maintains, such as who created file revisions in the depot, whether the file is a 'lazy copy,, the current state of client workspaces, protections, groups, users, labels, streams, and branches. Metadata is stored in the server database and is separate from the 'archive files' that users submit from their client workspace into the depot. database typically requires approximately 0.5 KB per user per file.

For example, a system with 50 users and 10,000 files initially requires about 250 MB.

Database size increases over time as file histories grow. The db.have table, which tracks files present in client workspaces, tends to grow faster than other database files.

If db.have becomes large and upgrading storage is not immediately possible, consider:

  • Deleting unused client workspace specifications.

  • Narrowing client workspace views.

Archive of versioned files

The archive grows as new file revisions are added. Allocate space in P4ROOT for:

Log files

Log file size depends on server activity and logging configuration. For more information, see Configure logging.

File-system guidance

When planning a P4 Server installation, disk performance and reliability are critical. The server relies heavily on the filesystem for metadata access and file version storage, so poor disk choices can significantly affect performance, stability, and recovery.

This section explains how P4 Server uses the filesystem and provides best-practice recommendations for where to store server data.

File-system performance

P4 Server is efficient in its use of disk I/O:

  • Metadata is well-indexed and accessed in mostly sequential scans.

  • The most disk-intensive operation is file check-in, when files are written to and renamed in the archive.

Overall server performance depends on:

  • The operating system’s filesystem implementation.

  • How directory updates are handled (synchronous vs asynchronous).

  • The speed and latency of the underlying storage hardware.

P4 Server does not require a specific filesystem or hardware configuration, but filesystem behavior can have a noticeable impact on performance and recovery characteristics.

Operating system considerations

P4 Server is compatible with Windows, macOS, and Linux operating systems.

Linux systems typically offer the best performance due to asynchronous directory updates.

However, asynchronous updates can increase the risk of data loss if power is interrupted unexpectedly.

This trade-off mostly affects recovery scenarios, not day-to-day operation.

Using NFS-mounted storage

P4 Server supports storage on NFS-mounted volumes, but performance depends heavily on:

  • The NFS implementation.

  • Network latency.

  • The performance of the backing storage.

Important considerations:

  • The NFS implementation must support the flock protocol.

  • On Linux and FreeBSD, database access over NFS can be slow due to file locking behavior.

  • If the journal is stored on NFS, all server operations will be slower.

Consider storing the database, depots, and journal on local disks or a low-latency SAN whenever possible. These limitations apply only to the P4 Server process (P4D). Client workspaces have always been able to reside on NFS-mounted storage (for example, users’ home directories).

Separate physical drives for server root and journal

The P4ROOT directory contains:

For best performance and recoverability, store P4ROOT and the journal on different physical disks.

This separation provides two key benefits:

  1. Improved recovery

    • If the disk containing P4ROOT fails, the journal remains intact

    • You can replay the journal to restore lost metadata

  2. Better performance

    • Separating journal writes from database reads reduces I/O contention

This layout is strongly recommended for all production installations.

Location of server root and the journal

When you install the server, you specify the locations of:

  • The metadata database (P4ROOT)

  • The journal file (P4JOURNAL)

You can also change these locations later by:

  • Moving the existing files.

  • Updating the server configuration accordingly.

For details, see the environment variables P4ROOT and P4JOURNAL in the P4 CLI Reference.

Location of versioned files

You can control where file content (archive files) is stored after installing P4 Server.

  • To change the storage location for all depots, use the server.depot.root configurable.

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

See also Backup and recovery and Location of db.* files, journal, and depot files.