15 messages in com.perforce.perforce-user[p4] What is the best platform for Pe...
FromSent OnAttachments
Martin Ellison11 Sep 2000 23:11 
tsh...@cisco.com12 Sep 2000 06:58 
Chuck Karish12 Sep 2000 08:08 
Steve Bennett12 Sep 2000 08:16 
tsh...@cisco.com12 Sep 2000 08:58 
Malcolm Beattie18 Sep 2000 09:18 
tsh...@cisco.com18 Sep 2000 09:26 
Bill Wishon18 Sep 2000 11:14 
Rick Macdonald18 Sep 2000 13:57 
Frank Merrow18 Sep 2000 14:42 
Rick Macdonald18 Sep 2000 15:18 
Frank Merrow18 Sep 2000 15:48 
Weiss, Adam18 Sep 2000 17:40 
Rick Macdonald18 Sep 2000 19:16 
Viktor Haag19 Sep 2000 08:51 
Subject:[p4] What is the best platform for Perforce?
From:tsh...@cisco.com (tsh@cisco.com)
Date:09/12/2000 08:58:11 AM
List:com.perforce.perforce-user

-----Original Message----- From: perforce-user-admin at perforce.com [mailto:perforce-user-admin at perforce.com]On Behalf Of Martin Ellison Sent: Tuesday, September 12, 2000 2:11 AM To: 'perforce-user at perforce.com' Subject: [p4] What is the best platform for Perforce?

We are considering a move to a dedicated Perforce box. So we have several questions:

1. What is the best system (hardware, operating system) for Perforce? Which systems have you used successfully as a platform for Perforce?

We initially used an UltraSPARC 5/Solaris, but switched to Linux for disk capacity and processor performance reasons.

The advantage of Solaris (and FreeBSD as well, I believe) is that it supports files over 2GB. Linux is currently limited to having 2GB files, and that becomes an issue with some of the database files especially db.have. However, unless you have lots of users/labels db.have's growth can be managed through restoring checkpoints, and cleaning out unused labels/clients/users/branches.

We passed the 2 GB mark in our databases when we had about 20 engineers and 200,000 files, with two years of history. If you're supporting a growing development group, you'll save yourself work in the future if you choose a system that doesn't have a 2 GB limit.

We're supporting in excess of 100 users on a Sun E420r with 450MHz processors and 2 GB of memory. We also run a lot of automated tests and code consistency daemons, which hit the server pretty hard.

We have a 500 MHz Pentium III/Xeon I believe. Our load average is fairly low, 99% CPU idle is not uncommon. We've reached into about 8MB of swap, not too bad... but I want to completely avoid it.

After 32 months and almost 50 users, our db.have file has not really grown beyond 400MB. We don't have 200,000 files, however, closer to 20,000. We have over 400 labels, and 126 clients, which I try to keep to a reasonable numbers. As far as I know, clients and labels are the main consumer of db.have, so if you keep tabs on them, you can clean them up. I have a P4DB web page I created that lists all the clients (P4DB doesn't do this as provided), and shows me the last access dates, etc. Once we release product, we are able to remove old labels of test versions.