4.6.5 Data Lifetime

     c['changeHorizon'] = 200
     c['buildHorizon'] = 100
     c['eventHorizon'] = 50
     c['logHorizon'] = 40
     c['caches'] = { 'changes' : 100 }
     c['buildCacheSize'] = 15

Horizons

Buildbot stores historical information about builds on disk in the form of "Pickle" files and compressed logfiles. In a large installation, these can quickly consume disk space, yet in many cases developers never consult this historical information.

The c['changeHorizon'] key determines how many changes the master will keep a record of. One place these changes are displayed is on the waterfall page. This parameter defaults to 0, which means keep all changes indefinitely.

The buildHorizon specifies the minimum number of builds for each builder which should be kept on disk. The eventHorizon specifies the minumum number of events to keep – events mostly describe connections and disconnections of slaves, and are seldom helpful to developers. The logHorizon gives the minimum number of builds for which logs should be maintained; this parameter must be less than buildHorizon. Builds older than logHorizon but not older than buildHorizon will maintain their overall status and the status of each step, but the logfiles will be deleted.

Caches

The caches configuration key contains the configuration for Buildbot's in-memory caches. These caches keep frequently-used objects in memory to avoid unnecessary trips to the database or to pickle files. Caches are divided by object type, and each has a configurable maximum size. The default size for each cache is 1, which allows Buildbot to make a number of optimizations without consuming much memory. Larger, busier installations will likely want to increase these values.

The available caches are:

1. Changes

   the number of change objects to cache in memory. This should be larger than the number of changes that typically arrive in the span of a few minutes, otherwise your schedulers will be reloading changes from the database every time they run. For distributed version control systems, like git or hg, several thousand changes may arrive at once, so setting this parameter to something like 10000 isn't unreasonable.

   This parameter is the same as the deprecated global parameter changeCacheSize.

2. chdicts

   The number of rows from the changes table to cache in memory. This value should be similar to the value for Changes.

3. BuildRequests

   the number of BuildRequest objects kept in memory. This number should be higher than the typical number of outstanding build requests. If the master ordinarily finds jobs for BuildRequests immediately, it can be set to a relatively low value.

4. SourceStamps

   the number of SourceStamp objects kept in memory. This number should generally be similar to the number BuildRequesets.

5. ssdicts

   The number of rows from the sourcestamps table to cache in memory. This value should be similar to the value for SourceStamps.

The global buildCacheSize parameter gives the number of builds for each builder which are cached in memory. This number should be larger than the number of builds required for commonly-used status displays (the waterfall or grid views), so that those displays do not miss the cache on a refresh.

     c['buildCacheSize'] = 15