[p4] Perforce server lockup problem
defoglesong at msn.com
Tue Mar 8 12:22:04 PST 2005
Any chance your branch and/or client specs use multiple ... wildcards on
each side of the view?
I've seen this make a huge difference in how long Perforce spins during
integrations. ("huge" = one case involved cleaning up branch specs to remove
the extra wildcards made the integration times go from 10-12 minutes to
Have you turned on server logging (-vserver=3) to see where Perforce is
spending the time?
>From: "Erik Johnson" <erik at valvesoftware.com>
>To: <perforce-user at perforce.com>
>Subject: [p4] Perforce server lockup problem
>Date: Mon, 7 Mar 2005 11:21:55 -0800
>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
>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.
>Come to the 2005 Perforce User Conference, April 14 & 15 in Las Vegas.
>Learn more: http://www.perforce.com/conf
>perforce-user mailing list - perforce-user at perforce.com
Dont just search. Find. Check out the new MSN Search!
More information about the perforce-user