[p4] Optmizing Perforce Databases

[Stephen Vance]

Nellie --

Where is the growth occurring, in the dbs or in the depot storage?

The two space hogs for dbs are usually db.have and db.label.

To control db.have, you need to keep the number of client workspaces 
under control and you need to narrow the client spec views to minimize 
the file contents. The size of db.have will tend to stabilize once your 
users stabilize in their usage levels and patterns.

To control db.label, use automatic labels or changelists as indicators 
instead of traditional labels populated by labelsync. The size of 
db.label commonly will increase by quanta related to the size of your 
source base and stay around forever unless you empty out or remove labels.

Huge growth in depot storage is usually tied to binaries.

Some other tables may grow depending on your usage patterns. Getting one 
of the PCPs to help you analyze it could give you a lot of mileage and 
some very tailored solutions.

Steve

Nellie Chen wrote:
> Hi,
>
> We are finding that our Perforce databases are growing in size extremely quickly, and is quickly running out of disk space.  We have almost 200 users accessing our Perforce server and they are all adding more data into the server.  Adding more disk space to the server will temporarily solve the problem.  We have initially calculated disk space to be 3 times the anticipated used space, but we are now quickly exceeding this limit.
>
> We are currently looking into re-indexing/re-building the Perforce databases, which may reduce the size of the dbs.  But are there other suggestions to:
> 1. Reduce the size of our current Perforce dbs?
> 2. Help optimize/control the growth of the Perforce dbs in the future (without hindering developers from making check-ins)?
>
> Thanks,
> Nellie
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>   

-- 
Stephen Vance
www.vance.com