Database

Database concurrency is assisted by allowing Commands implementing lockless reads to take a quick 'peek' at certain database tables. This ensures that write operations on these tables can run immediately, rather than being held until the read-lock is released.

Possible values for db.peeking

If you want to change the setting of lockless reads on your Helix Core Server, use the p4 configure set db.peeking=N command to set the value of the db.peeking configurable.

Value	Meaning
`0`	If `db.peeking` is unset or `0`, the old database locking order is used and lockless reads ("peeking") are disabled. This corresponds to the behavior of Helix Core Server at release 2013.2 and below.
`1`	If `db.peeking` is set to `1`, the new database locking order is used, but peeking remains disabled. This configuration is intended primarily for diagnostic purposes.
`2` (default)	If `db.peeking` is set to `2`, the new database locking order is used and lockless reads ("peeking") are enabled. This configuration is expected to provide the best performance results for most sites. It is the default value.
`3`	If `db.peeking` is set to `3`, the new database locking order is used and lockless reads ("peeking") are enabled, but optimizations for the `db.revhx` and `db.revdx` tables are bypassed. This configuration involves a trade-off between concurrency and command completion speed. In general, if a repository has many revisions per file, some commands complete more slowly with `db.peeking=3`, but no longer require read locks on the `db.revhx` and `db.revdx` tables. If read locks on these tables are the bottleneck, overall performance might still be better with `db.peeking=3`. One guideline: if you have lots of history, use the default; if you have lots of single revision branch data, try `db.peeking=3`; if you max out cpu, go back to the default (`2`).

No server restart is required if you are using Helix Core Server 2017.1 or later.