[p4] Perforce server lockup problem

DAVID Foglesong 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?
eg,
//depot/dev/project/.../source/...   
//depot/users/bob/project/.../source/...

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 
30-40 seconds.)

Have you turned on server logging (-vserver=3) to see where Perforce is 
spending the time?

David Foglesong



>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
>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.
>
>
>_______________________________________________
>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
>http://maillist.perforce.com/mailman/listinfo/perforce-user

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/




More information about the perforce-user mailing list