[p4] Perforce server lockup problem

Smith, Jeremy R (CACI) JeremyRobert.Smith at med.va.gov
Mon Mar 7 23:17:37 PST 2005

I have never seen behavior like this...the closest that we have seen are database write slowdowns having to do with AntiVirus software.  Are you sure it's the perforce process that's introducing the disk writes?
I swear by Mark Russinovich's tools at http://www.sysinternals.com to show what's really happening on the system.
I would also consider checkpointing the database and restoring from the checkpoint.  

-----Original Message-----
From: perforce-user-bounces at perforce.com [mailto:perforce-user-bounces at perforce.com]On Behalf Of Erik Johnson
Sent: Monday, March 07, 2005 12:22 PM
To: perforce-user at perforce.com
Subject: [p4] Perforce server lockup problem

I'll try and give as much data on our setup, along with the problem we've been having. I haven't gotten any really crisp leads from Perforce support on this problem. Maybe someone else has already solved it.
We're running our Perforce server on Windows 2003 server on a machine with 2GB RAM, a RAID 5 disk subsystem with 7200RPM SATA drives, and a single 3.GHz HT processor. We're running server version P4D/NTX86/2004.2/73359 (2004/12/27).
Our general workflow (and the one that tends to generate the problem) is that we have a main branch that few people directly work on, with personal branches off of it that individual developers integrate into. There are roughly 20 developers integrating roughly 5,000 lines of code a day. Unfortunately, we changed a couple of variables at once when the problem started happening (upgraded server software, server hardware), so I can't reasonably point to a specific root cause.
When a developer is merging from their personal branch into our main codeline, we're seeing total database lockup, and constant reads on the server (viewed via Windows perfmon). This means that all other users on the system cannot sync, integrate, checkout, checkin, etc. The condition generally takes around 15 minutes to clear, and then things all go back to normal. CPU and RAM usage on the system is all nominal, and while the reads on the disk subsystem are constant, they are not within 1/3 of the observed peak read throughput.
Has anyone else seen behavior like this? It appears that the database is being read table by table for some reason.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.perforce.com/pipermail/perforce-user/attachments/20050308/e866f429/attachment-0007.html>

More information about the perforce-user mailing list