[p4] Optmizing Perforce Databases
steve at vance.com
Thu Feb 14 12:38:44 PST 2008
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.
Nellie Chen wrote:
> 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)?
> perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user