Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.1

# Limit database queries and Server resources

These fields in the Group spec can limit database queries and the amount of Server resources available to any single command by any single member of the group:

Field Name | Description
--- | ---
`MaxResults:` | The maximum number of results that members of this group can access from the service from a single command. This prevents the server from using excessive memory by limiting the amount of data buffered during command execution. Users in limited groups are unable to run any commands that buffer more database rows than the group’s `MaxResults` limit. (For most sites, `MaxResults` should be larger than the largest number of files anticipated in any one user’s individual client workspace.)
`MaxScanRows:` | The maximum number of rows that members of this group can scan from the service from a single command. This prevents certain user commands from placing excessive demands on the server. (Typically, the number of rows scanned in a single operation is roughly equal to `MaxResults` multiplied by the average number of revisions per file in the depot.)
`MaxLockTime:` | The maximum length of time (in milliseconds) that any one operation can lock any database table when scanning data. This prevents certain commands from locking the database for prolonged periods of time. Set `MaxLockTime` to the number of milliseconds for the longest permissible database lock.
`MaxOpenFiles:` | The maximum number of files that a member of a group can open using a single command.
`MaxMemory:` | Maximum amount of megabytes of random-access memory that a command can use when run by any member of this group.

For convenience, we refer to this set of fields as the "MaxLimit" fields. The default for each "MaxLimit" field is `unset`, but a superuser can use `p4 group` to set limits.

Example: Effect of setting "MaxLimit" fields

As an administrator, you want members of the group `rocketdev` to be limited to operations that involve no more than 20,000 files, scan no more than 100,000 revisions, lock database tables for no more than 30 seconds, open no more than 1000 files, and consume no more than 2000 megabytes of memory:

    Group:        p4 rocketdev
    MaxResults:   20000
    MaxScanRows:  100000
    MaxLockTime:  30000
    MaxOpenFiles: 1000
    MaxMemory:    2000
    Timeout:      43200
    Subgroups:
    Owners:
    Users:
            bill
            ruth
            sandy

Suppose that Ruth is a member of this group and has an unrestricted (loose) client view. She types:

    $ p4 sync

Her `sync` command is rejected if the depot contains more than 20,000 files. She can work around this limitation either by restricting her client view, or, if she needs all of the files in the view, by syncing smaller sets of files at a time:

    $ p4 sync //depot/projA/...
    $ p4 sync //depot/projB/...

Either method enables her to sync her files to her workspace, but without tying up the server to process a single extremely large command.

Ruth tries a command that scans every revision of every file, such as:

    $ p4 filelog //depot/projA/...

If there are fewer than 20,000 revisions, but more than 100,000 integrations (perhaps the `projA` directory contains 1,000 files, each of which has fewer than 20 revisions and has been branched more than 50 times), the `MaxResults` limit does not apply, but the `MaxScanRows` limit does.

In addition, no command is permitted to lock the database for more than the `MaxLockTime` of 30,000 milliseconds or consume more than 2000 megabytes of memory.

To remove any limits on the number of result lines processed (or database rows scanned, or milliseconds of database locking time) for a particular group, set the `MaxResults` (or `MaxScanRows` or `MaxLockTime`) value for that group to `unlimited`.

Because these limitations can cause difficulties for your users, do not use them unless you find that certain operations are slowing down your server. Because some P4 Server applications can perform large operations, you should typically set:

- `MaxResults` no smaller than 10,000

- `MaxLockTime` within the 1,000-30,000 (1-30 second) range.

- `MaxScanRows` no smaller than 50,000

For information on all the "MaxLimit" fields, see the output of the command-line help for any of the "MaxLimit" fields. For example, the output of

    $ p4 help maxopenfiles

The output is identical for all the "MaxLimit" fields and includes tips on how to adjust a command to run within the limit.

## Limits for users in multiple groups

If a user is listed in multiple groups, the highest numeric `MaxResults` limit of all the groups a user belongs to is the limit that affects the user.

The default value of `unset` is not a numeric limit. If a user is in a group where `MaxResults` is set to `unset`, that user is still limited by the highest numeric `MaxResults` (or `MaxScanRows` or `MaxLockTime`) setting of the other groups of which this user is a member.

A user’s commands are unlimited only when the user belongs to no groups, or when any of the groups of which the user is a member have their `MaxResults` set to `unlimited`.

Ticket Timeout and PasswordTimeout values for users who belong to multiple groups are calculated to be the largest timeout value for all the groups of which the user is a member, including unlimited, but ignoring unset.

A user who is not a member of any group has the default ticket Timeout value of 43200 seconds, which equates to twelve hours, and the PasswordTimeout value of unset.

To create a ticket that does not expire, set the ticket Timeoutvalue to unlimited.

### Testing "MaxLimits" on specific commands

Use the `-z{"MaxLimit"}` global option to immediately see the effect of any of the "MaxLimit" fields. For example, to check the impact of a `MaxScanRows` limit on a given command:

`$ p4 -zmaxScanRows=100000 sync Too many rows scanned (over 100000); see 'p4 help maxscanrows'.`

Your search for returned results