p4 servers lists all server specifications stored at a master Perforce server.

depot-master server depot-master myHost:1111 depot-master 'depot-master '
depot-standby_1 server depot-standby_1 10.0.101.55:37046 depot-standby 'depot-standby '
workspace-server_1 server workspace-server_1 10.0.101.55:41261 workspace-server 'workspace-server '
workspace-server_2 server workspace-server_2 10.0.101.55:47050 workspace-server 'workspace-server '

Output lists the server ID, the type, the services provided, and the description supplied when the server was created.

The output of p4 servers may be easier to parse if you retrieve it in tagged form:

p4 -ztag servers

... ServerID depot-master
... Name depot-master
... Address myHost:1111
... Type server
... Services depot-master
... Description depot-master


... ServerID depot-standby_1
... Name depot-standby_1
... Address myHost2:37046
... Type server
... Services depot-standby
... Description depot-standby


... ServerID workspace-server_1
... Name workspace-server_1
... Address myHost3:41261
... Type server
... Services workspace-server
... Description workspace-server


... ServerID workspace-server_2
... Name workspace-server_2
... Address myHost4:47050
... Type server
... Services workspace-server
... Description workspace-server

Using the -J or --replication-status option allows you to check how efficiently one or more replicas are replicating the master server’s records. Given a server A and a replica B, output for this command gives you two basic pieces of information:

This assumes that the command is executed with the master server as the target. A standby server can replicate master server records using two operations:

You can look at the output to evaluate the load on various parts of your distributed system and to see how well your replicas are keeping up with the master. Growing lag times might be a reason for concern.

The untagged output of p4 servers -J looks like this:

depot-master '2014/09/08 13:13:58' depot-master 5/258 5/258 wadL/1 1
depot-standby_1 '2014/09/08 13:14:58' depot-standby 5/258 5/258 WAdl/12 1
workspace-server_1 '2014/09/08 13:14:58' workspace-server 5/258 5/258 WaDl/10 1
workspace-server_2'2014/09/08 13:14:57' workspace-server 5/258 5/258 WaDl/10 1

It is easier to interpret this output in tagged form:

... ServerID depot-master
... Updated 2014/09/08 13:13:58
... ServerType depot-master
... PersistedJournal 5
... PersistedSequence 258
... AppliedJournal 5
... AppliedSequence 258
... JAFlags wadL/1
... IsAlive 1

... ServerID depot-standby_1
... Updated 2014/09/08 13:14:58
... ServerType depot-standby
... PersistedJournal 5
... PersistedSequence 258
... AppliedJournal 5
... AppliedSequence 258
... JAFlags WAdl/12 1
... IsAlive 1

... ServerID workspace-server_1
... Updated 2014/09/08 13:14:58
... ServerType workspace-server
... PersistedJournal 5
... PersistedSequence 258
... AppliedJournal 5
... AppliedSequence 258
... JAFlags WaDl/10 1
... IsAlive 1

... ServerID workspace-server_2
... Updated 2014/09/08 13:14:57
... ServerType workspace-server
... PersistedJournal 5
... PersistedSequence 258
... AppliedJournal 5
... AppliedSequence 258
... JAFlags WaDl/10 1
... IsAlive 1

The meaning of the fields are described in the following table.

Pull or journal-copy requests are recorded in the db.jnlack table only when made from a replica that has either a server ID or a P4NAME. Any replica that makes such a request but does not have a server ID or P4NAME is not recorded in the table.