Improving concurrency with lockless reads (peeks)

Prior to Release 2013.3, commands that only read data from the database take a read-lock on one (or more) database tables. Although other commands can read from the tables at the same time, any commands attempting to write to the read-locked tables are forced to wait for the read-lock to complete before writing could begin. Currently, the default behavior is to allow some commands to perform lock-free reads (or "peeks") on these tables, without sacrificing consistency or isolation. This provides significant performance improvement by ensuring that write operations on these tables can run immediately, rather than being held until the read-lock is released.

To change the setting of lockless reads on your Helix Core Server, use the p4 configure set db.peeking=N command.

Tip

db.peeking is a dynamic configurable, but prior to the 2017.1 release, a change to the value of this configurable required a server restart.

Possible values for db.peeking

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).