Open topic with navigation

p4 monitor

Display Perforce process information; control long-running tasks.

Syntax

p4 [g-opts] monitor show [-a -l -e -L -s R | T | P | B | F | I ]
p4 [g-opts] monitor terminate id
p4 [g-opts] monitor clear [id | all]
p4 [g-opts] monitor pause id
p4 [g-opts] monitor resume id

Description

p4 monitor allows a system administrator to observe and control Perforce-related processes running on a Helix Core server machine. Processes are tracked using a dedicated table that is constantly updated; this has a minor impact on server performance.

To use p4 monitor, you must enable monitoring on the Perforce service by setting the monitor configurable with p4 configure. You control process monitoring by setting the monitor configurable to one of the following values:

• 0 — disable monitoring
• 1 — enable monitoring of active processes
• 2 — enable monitoring of both idle connections and active processes
• 3 — enable idle connections stuck at Init(), idle connections and active commands.
• 5, 10, and 25 — obtain lock information. See the description of the L option for more information.

Changes to the monitor configurable affect all new p4 processes that connect to the server; restarting the server is not required.

Command syntax variants provide the following alternatives:

• To list current process information, use p4 monitor show. By default, all processes are listed, but only the command (for example, sync, edit, submit) is shown, without arguments. This form of p4 monitor requires list level access. Use the -s status option to restrict the display to processes in the specified state.

  To show the list of arguments associated with each command, use the -a (arguments) option or -l (long) option. For additional information from the user environment, use the -e (environment) option. These options require super level access. Use the -L option to show locked files.

• To mark a process for termination, use p4 monitor terminate id. This command requires that the user be an operator or have super level access.

  The p4 monitor terminate command will not mark a process for termination unless the process has been running for at least ten seconds. Some commands, such as p4 obliterate, cannot be terminated.

  To control how often the list of processes is refreshed, see the Configurable, db.monitor.interval, which is also mentioned in "Fixing a hung Helix Core server" at http://answers.perforce.com/articles/KB/3785

• To remove an entry from the monitor table, use p4 monitor clear id. You can clear the entire table with p4 monitor clear all. Both of these commands require super level access. ( If a command terminates prematurely on the server side, it may be erroneously listed as running. You can clear such processes with p4 monitor clear. )

  Requires that the user be an operator or have super access.

  Processes marked as running continue to run to completion even if removed from the monitor table with p4 monitor clear.

• To control long-running tasks such as p4 verify or p4 pull, use the p4 monitor pause and p4 monitor resume commands.

  p4 monitor pause and p4 monitor resume require that the user be an operator or have super access.

Output format

Each line of p4 monitor output consists of the following fields:

pidstatusownerhh:mm:sscommand [args]

For example, consider the following output to the p4 monitor show -L command, which displays information about locked files:

8764 R user 00:00:00 edit
      [server.locks/clients/88,d/ws4(W),db.locks(R),db.rev(R)]
8766 R user 00:00:00 edit
      [server.locks/clients/89,d/ws5(W),db.locks(R),db.rev(R)]
8768 R user 00:00:00 monitor

Following pid, status, owner, and time information, this shows two edit commands that have various files locked, including the client workspace lock in exclusive mode for the workspaces ws4 and ws5, and db.locks and db.rev tables in read-only mode.

If you have enabled idle process monitoring (by setting the monitor configurable to 2), idle processes appear with a status of R, but with a command of IDLE.

Some commands (for instance, p4 submit) invoke multiple processes. For example, dm_CommitSubmit or dm_SubmitChange may appear in the output of p4 monitor as two separate phases of the p4 submit command.

Getting pull thread information for replicas

If you are running a replica with monitoring enabled and you have not configured the monitor table to be disk-resident, you can run the following command to get more precise information about what pull threads are doing. (Remember to set monitor.lsof).

$ p4 monitor show -sB -la -L

Command output would look like this:

31701 B uservice-edge3 00:07:24 pull sleeping 1000 ms
    [server.locks/replica/49,d/pull(W)]

Options

You must be an operator or have super access to use the following options.

Usage Notes

Examples

Related Commands