[p4] What actually happens during checkpoint

Ivey, William william_ivey at bmc.com
Thu Mar 5 13:30:18 PST 2009


As far as I can tell, checkpoints are just serialized representations of
the db tables - each table's data is grouped together.

If you have a lot of obsolete clients or labels, consider removing them. 
Those can generate quite a bit of extra data.

Given the ratio of live to compressed data, I'd agree with the others
who recommend restoring it to clean out the accumulated dead space.
(Clean up the obsolete objects first to increase your savings.)

-Wm


-----Original Message-----
From: perforce-user-bounces at perforce.com [mailto:perforce-user-bounces at perforce.com] On Behalf Of Jamie.Echlin at barclayscapital.com
Sent: Thursday, March 05, 2009 8:26 AM

Can anyone help me understand what happens during a checkpoint?
Background is, the checkpoint procedure has got incredibly slow, about 9
hours to produce a 4.5 G compressed checkpoint from a 104G database.

We have some problems with our SAN. The LUNS that make up the data
volume are split over two different array controllers, one of them in a
different data centre. However, this shouldn't cause problems in itself,
it's just not "best practice", or so I've been told.

My theory about the performance then was that the checkpoint would write
the transactions in the same order that they were originally done,
causing reads over all the different tables, somehow exacerbating a disk
problem. Also we don't have enough main memory, only 32G. However,
reading more, checkpoints are not the same as journals, the transactions
are not in the same order. But a checkpoint is also not just a
compressed copy of all the tables, if that was true there was no way it
could so long. So what gives? ;-)

A restore of a checkpoint takes 10 hours, so not much difference between
reads and writes. Just to rule out decompressing being the bottleneck,
it's only using a couple per cent of CPU.

Cheers, jamie




More information about the perforce-user mailing list