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 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, then some commands will complete more slowly with db.peeking=3, but will no longer require read locks on the db.revhx and db.revdx tables. If read locks on these tables are in fact the bottleneck, overall performance may 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.