Filesystem
File size and disk I/O are the key issues here. For more information, see File systems.
Filesystem performance
Helix server is judicious with its use of disk I/O. Helix 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 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 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 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 server
applications, (such as p4
, the
Helix 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
We recommend that the P4ROOT
directory (that is, the directory containing your
database and versioned files) be on a different physical drive than your
journal file:
- By storing the journal on a separate drive, you can be reasonably
certain that, if a disk failure corrupts the drive containing
P4ROOT
, such a failure will not affect your journal file. You can then use the journal file to restore any lost or damaged metadata. - Separating the live journal from the
db.*
files can also improve performance.
See Backup and recovery and in Journal and archive location.
Your search for returned result(s).