This is a Python script (tested on Python 2.5, but 2.4 should work as well) script to monitor the performance of a Windows Perforce server. Both client and server need to run on Windows XP / Server 2003 or later, and the server should be reachable over Windows networking. It uses the standard Windows Typeperf tool to query performance counters on the server. This requires (Windows) admin access to the server. It also uses the Sysinternals (now Microsoft) tool PsList, which can currently be found at: http://www.microsoft.com/technet/sysinternals/utilities/pslist.mspx Just put pslist.exe next to the script, so it can find it. Also, make sure the other files from this directory are present next to the script. The Perforce server must have monitoring enabled, if necessary, turn monitoring on with: p4 counter -f monitor 1 and restart the server. To get the most out of the script, Perforce admin access is also required. Specify the name of an admin account to use at the top of the script. If a password is required for this account and no valid ticket is present, the script will ask for the password at startup. If the admin login fails, the script will still run, but with less detailed output. A good trick to get round the admin access, and also to enable monitoring a server that has become (nearly) unresponsive, is the following: - Run a second “monitoring” p4s on the server (on, say, port 1665), with it's own db directory. - Delete the monitor.db of the second server, and replace it (using fsutil) by an NTFS hardlink to the main server monitor.db. - Now, running ‘p4 monitor’ on the second server will give you all the information from the main server monitor.db, even if that one is completely unresponsive. An additional advantage is that, if we keep the second server without an admin password (there is nothing of value in there, so this shouldn’t be a big problem), monitoring scripts such as this one won’t need to mess around with admin passwords or everlasting tickets The script uses typeperf counters to get the server stats, these need to be configured at the top of the script so that it will query the right disk and network interfaces. To get a full list of available counters, do: typeperf -qx \\server_name The network interfaces can be found in the list as \\server_name\Network Interface(NAME)\... The NAME is what should be specified as the typeperf counter below. Disk interfaces can be found as: \\server_name\PhysicalDisk(NAME)\... Figuring out which are the right interfaces isn't always easy, especially in a server with lots of disks and network interfaces. Still, a bit of experimenting should give you the right ones. I've left some sample values in the fields in the script so you know what sort of thing to look for. The output should mostly be obvious: All sizes are in megabytes (MB), not bits. p4[s|d] memory usage is shown as Virtual / Physical. If Virtual memory usage of p4s gets anywhere near the total amount of physical memory, you're likely to run into lots of swapping and performance problems. P4 threads are sorted according to the time they have been running, with the longest one at the top. Runtime is listed as hh:mm:ss. Cpu % per thread is a % to total cpu available. So on (say) a 4 core machine, a single thread can never use more than 25% of cpu and if that happens that thread has become cpu-bound. However, the Cpu % for proxy / client are per Cpu (or core), so these can go to 100%. The Connection column can be useful to see if everybody is using the right proxy/server connection (in which case the Workspace column can help in determining where the query originated). Just what exactly the disk usage % means is a bit tricky to explain, but it is a reasonable indicator of disk usage. If it's 0%, nobody is using the disk at all, and if it's at 100%, the disk has become a bottleneck. You can either run the script locally, or install it as a service on a webserver. The latter works best to keep a constant watch on the server. Here's what you need to do to set this up: - First of all, make sure the script is configured properly and outputs the html you want. - Install the Win2K Resource Kit (or obtain srvany.exe and instsrv.exe from elsewhere) - Install a p4mon service as follows (adjust paths as necessary): C:\Program Files\Resource Kit\instsrv p4mon "C:\Program Files\Resource Kit\srvany.exe" - Check that p4mon is now listed as a Windows Service, and make sure that the Startup Type is automatic. - Edit (or create, keys should be REG_SZ) the following registry entries, adjusting the paths as necessary. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\p4mon\Parameters] "Application"="C:\\Python25\\Python.exe" "AppParameters"="C:\\p4mon\\p4mon.py -o htdocs\\index.html -e address@host -m mailserver" "AppDirectory"="C:\\p4mon\\" - In this example: C:\\p4mon\\ is the location of the the p4mon script. C:\\Python25\\Python.exe is the path to the Python executable. htdocs\\index.html is the path to the html file that will be output. address@host is the email address that any exceptions will be mailed to. mailserver is the name of the mailserver to use. - Restart the p4mon service and verify that it generates the html output you want. - Make sure the path to the generated html is reachable through the local webserver, open that path in a webbrowser and enjoy your p4mon stats. The end result is a webpage that you can easily consult to instantly see if the Perforce server is running smoothly, or if it's in trouble, and, if so, give you some clues as to the cause of the trouble. Please send any questions or comments to me: email@example.com Frank Compagner September 21, 2007.