[p4] Next Question - Hardware setup
sstevens at adobe.com
Wed Nov 1 16:11:09 PST 2006
Are you using Solaris x86 or Solaris Sparc architecture? For Perforce's
database intensive operations, we have found Solaris on x86 to be
roughly twice as fast as on Sparc, on the latest Sun machines of both
types. Sun's x4600 servers are quite impressive. Load them up with RAM
and assign lots of it for file cache for best results.
We have about 3000 users on a dozen servers and deal with Perforce
jam-ups continually. The main causes are:
-> remote depot browsing - my monitoring scripts tail the log files
and now kill these automatically.
-> huge syncs - new users often sync everything in their default view.
These are killed automatically when they use more than 2 GB of RAM, but
they've locked things up for a while by then.
-> integration - a nag email tells everyone to use the undocumented -1
integ argument to force direct integration (we are using release 2004.2)
unless they are sure they can't. I also provided a script that splits
large integrations into chunks, that helped a lot. This includes
integrations that update the mainline from a sandbox branch. Every file
on the branch is considered, even if only a few actually need
-> submit - nothing you can do about big submits but get a faster
machine, do more user education about not doing integrate -f (for
instance), and asking people to do them after hours. Our tests are
showing large submits to be slower in 2006.1 than 2004.2, but we're
still getting to the bottom of that.
-> file searches - unfortunately, Perforce doesn't deal with embedded
wildcards in paths very well. When the wildcards are at the top of a
large file tree, the searches go hyperbolic and use lots of server cpu.
"p4 fstat //.../*.cps", for instance. They also slow syncs and other
operations down quite a bit. I advise people to search their synced
files using an OS native tool, or if that is not practical, search the
output of "p4 files //depotname/...". Also watch out for embedded
wildcards in client spec views, branch specs, and the protect table.
There are others, but these are the main culprits. We address most of
them with monitoring scripts that tail the log file (we run p4d with
-vserver=3), and use ps to watch process size and cpu usage.
: Adobe Systems, Inc.
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Venters, Cheryl
Sent: Wednesday, November 01, 2006 11:05 AM
To: perforce-user at perforce.com
Subject: [p4] Next Question - Hardware setup
Let me throw out my next question. We are currently running p4 on
Solaris 9. Db files and the journal used to sit on our SAN but have
moved them to the local disk. Performance did improve when we made that
move. We are looking at improving our hardware to support MUCH better
performance and are looking for recommendations from other Solaris
users. I'm also getting input from Perforce tech support but would love
to hear from people actually running Solaris. Currently have 565 users,
over 750 checkins a day, 100MB on versioned files.
perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user