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 preventa 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 Helix Core 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

Tip

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.

Note

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