One of the most common problems seen on Windows is related to virus checkers. Because there is a constant battle between the latest virus and the most thorough virus checker, a Windows application like the Perforce Server often becomes a casualty.
The Perforce metadata is contained in the db.* files under the Perforce Server root directory. The Perforce Windows Server expects to be the only application accessing the Perforce metadata. Internally, the Perforce Server uses file locking to synchronize multiple client access to critical sections in the metadata.
Many virus checkers have a dynamic feature that monitors files as they are in use. As soon as the file has been opened, created, or updated, the virus checker pre-empts this access and opens and scans the file. This virus scan can block the Perforce Server from completing its current request or processing the next client request. This blocking can even generate a serious DB error in the Perforce Server, and terminate the client request. Depending on the severity of the error, the Perforce Server might also shut down. Because of that, you want to configure your Virus Checker to never scan open files owned by Perforce.
Use of a virus checker should be avoided on a Perforce Server machine. If possible, use a dedicated machine for your servers. Use a strategy that shields the dedicated server from outside influence. Create a fully-populated Perforce client workspace and run a virus checker there. If you have to run a virus checker on the Perforce Server machine, ensure first that any real-time virus-checking is not only disabled, but uninstalled. Then, ensure that scheduled checking does not check the metadata files. Do not allow virus checkers to filter the Perforce Server's TCP/IP traffic.
Reverse DNS Lookup
Perforce clients run reverse DNS lookups. To speed performance, run:
Where 10.0.95.98 is replaced with the Perforce Server's IP address. If the result is the Perforce Server's name, then DNS reverse lookups are working. If the result is an error, then add an entry to C:\WINDOWS\system32\drivers\etc\hosts.
Where perfserver is the Perforce Server's name and 10.0.95.98 is the Perforce Server's IP address.
Logitech Video Driver
The Logitech Video driver, LVPrcSrv.exe, is known to cause the Perforce Windows installer to exit. This video driver intercepts installer calls to the Win32 API DuplicateHandle function causing an immediate installer exit without the possibility of collecting an error. The only known work-around, to date, is to kill the LVPrcSrv.exe process in the Task Manager, run the Perforce Installer, then restart the LVPrcSrv.exe process. Logitech is aware of this problem.
Missing Checkpoint and Depot Backups
Perform regular Perforce Server checkpoints. For more information on Perforce backup and recovery concepts, consult our System Administrator's Guide. Your checkpoints are complete if the current journal has been renumbered and a new journal file has been created. The output from a typical checkpoint operation using command p4d -jc is similar to the following:
Checkpointing to checkpoint.83...
Saving journal to journal.82...
If you are using p4 admin checkpoint, you will not see this output.
Note the last line is indicating the creation of a new journal. If this line is missing from your checkpoint output, there is a good chance your checkpoint is incomplete. If this line is missing, call or email Perforce Technical Support at firstname.lastname@example.org.
Establish good system backup practices. Verify that your backups are working. Most importantly make sure that you can recover from the backup device. Many times users do not realize that backups are failing or a recovery is not possible until it is too late.
Disk Space Capacity
Make sure the Perforce Server machine has plenty of disk space. If the Perforce Server overruns the disk space, metadata corruption can occur. If you suspect you have run out of disk space, you can check the Perforce Server metadata using the command p4d -xv while in the Perforce Server root, P4ROOT, directory.
You can conserve space used in checkpoints by using the -z flag when creating a checkpoint, like so:
p4d -z -jc
When checkpoints are performed and verified, you need to keep only the last 2 or 3 checkpoints and corresponding journal files for safety; although this does depend on your system backup scheduling.
Note: Always confirm that the latest checkpoint is good before discarding old checkpoints and numbered journal files. Failure to do so could result in not having a good backup of your Perforce meta-data.
Automatic Windows Updates
Microsoft supplies a convenient method to apply Windows updates. We suggest Windows updates be applied manually. If possible, select the backup option in case the update must be removed. Schedule the updates to better determine before or after system instabilities. At a minimum, apply the security patches which help prevent system security attacks. As a general rule of thumb Perforce tries to support the latest security updates. If you notice problems after a security update please call or email Perforce Technical Support at email@example.com. Make sure to inform the Perforce Technical Support engineer that this issue might be related to a Windows update.
System Memory Usage
If you are managing a large site, it is important to note that the Windows x86/32-bit application can only use up to 2 GBytes of virtual memory. If your Perforce Service is approaching 2 GB of memory usage, there is a Perforce Server for Windows x64/64-bit that might help. 64-bit Windows systems are not affected by the 2GB memory limit. The 2006.2 and later Windows installers contain two Perforce Servers, NTX86 and NTX64. The installer auto-detects which one is installed.
We recommend against using either the /3GB or /PAE Windows 32-bit boot.ini flags due to Windows 32-bit performance issues.
Network Disk Performance
Using a network disk for the Perforce Server metadata slows server performance. Latency due to a network's round-trip-time can severely impact Perforce performance, because Perforce issues thousands of file requests per second, and thus any tiny latencies are amplified many times. In nearly all of Perforce's testing, DAS (directly-attached-storage) systems are faster.
Some larger sites use network storage for Perforce Server versioned files. Try to use a Gigabit or faster network connection between the Perforce Server machine and the network storage device, and ensure that the bandwidth (if not latency) for your needs will be adequate.
There is a disk throughput testing tool available if you are interested in testing your disk performance. Email Perforce Technical Support at firstname.lastname@example.org, and ask for the "fstst" tool.
Windows Service Permissions
The Perforce Service is, by default, configured by the Perforce Windows installer to use the LocalSystem user account. In some cases it is necessary to assign a different user account to the Perforce service. This user account must have access to the machine registry. You can verify access to the registry by logging on as that user and running this command:
p4 set -S Perforce
If this command succeeds, the user account has the necessary permissions on the registry. The user account must also have access to the directory structure under the Perforce Server root (P4ROOT). If in doubt about this access, try creating a file or directory as this user under the intended Perforce Server root directory.
Running out of TCP ports
Perforce communicate with a client over a TCP port. On a loaded server serving many TCP connection you may hit the soft-limit in Windows. While the defaults is relatively large, it may not be large enough for your environment. Microsoft has a knowledge base article on how to increase the number of available TCP ports and to decrease the timeout before a port is released to be used: