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

P4 Server Administration Documentation | 2026.1

# p4 pull command

The `p4 pull` command retrieves metadata or versioned files from a target server to its standby or replica, or displays status information about pending transfers.

You can use p4 pull to check the state of metadata and archive P4 replication. To learn more, see Inspecting replication progress in the Perforce Knowledge Base.

The p4 pull command provides the most general solution for replication. Use `p4 pull` to configure a replica server that:

- Replicates file revisions from a target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'..
- Replicates server metadata from a target server.

- Uses the `startup.N` configurable to automatically spawn as many `p4 pull` processes as required.

  A common configuration for a replica server is one in which one (and only one) `p4 pull` process is spawned to replicate the target server’s metadata, and multiple `p4 pull -u` processes are spawned to run in parallel, and continually update the replica’s copy of the target server’s versioned files.

- The `startup.n` configurables are processed sequentially. Processing stops at the first gap in the numerical sequence. Any commands after a gap are ignored.

Although you can run `p4 pull` from the command line for testing and debugging purposes, it’s most useful when controlled by the `startup.n` configurables, and in conjunction with named servers, service users, and centrally-managed configurations.

The `--batch` option to the `p4 pull` specifies the number of files a pull thread should process in a single request. The default value of `1` is usually adequate. For high-latency configurations, a larger value might improve archive transfer speed for large numbers of small files. (Use of this option requires that both target server and replica be at version 2015.2 or higher.)

Setting the `rpl.compress` configurable allows you to compress journal record data that is transmitted using `p4 pull`.

## Precise monitoring

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

The possible status messages are:

For journal records | For pulling archives
--- | ---
`scanned NNNN records` | `sleeping`
`applied NNNN records` | `running`
`rotating journal` |

## p4 pull vs. p4 replicate

P4 Server also supports a more limited form of replication based on the p4 replicate command. This command does not replicate file content, but supports filtering of metadata on a per-table basis.

Your search for returned results