3.7. Compaction

3.7.1. Database Compaction Options

[database_compaction]

  • doc_buffer_size

    Specifies the copy buffer’s maximum size in bytes:

    1. [database_compaction]
    2. doc_buffer_size = 524288

  • checkpoint_after

    Triggers a checkpoint after the specified amount of bytes were successfully copied to the compacted database:

    1. [database_compaction]
    2. checkpoint_after = 5242880

3.7.2. View Compaction Options

[view_compaction]

  • keyvalue_buffer_size

    Specifies maximum copy buffer size in bytes used during compaction:

    1. [view_compaction]
    2. keyvalue_buffer_size = 2097152

3.7.3. Compaction Daemon

CouchDB ships with an automated, event-driven daemon internally known as “smoosh” that continuously re-prioritizes the database and secondary index files on each node and automatically compacts the files that will recover the most free space according to the following parameters.

[smoosh]

  • db_channels

    A comma-delimited list of channels that are sent the names of database files when those files are updated. Each channel can choose whether to enqueue the database for compaction; once a channel has enqueued the database, no additional channel in the list will be given the opportunity to do so.

  • view_channels

    A comma-delimited list of channels that are sent the names of secondary index files when those files are updated. Each channel can choose whether to enqueue the index for compaction; once a channel has enqueued the index, no additional channel in the list will be given the opportunity to do so.

  • staleness

    The number of minutes that the (expensive) priority calculation on an individual can be stale for before it is recalculated. Defaults to 5.

  • cleanup_index_files

    If set to true, the compaction daemon will delete the files for indexes that are no longer associated with any design document. Defaults to false and probably shouldn’t be changed unless the node is running low on disk space, and only after considering the ramifications.

  • wait_secs

    The time a channel waits before starting compactions to allow time to observe the system and make a smarter decision about what to compact first. Hardly ever changed from the default of 30 (seconds).

[smoosh.<channel>]

The following settings control the resource allocation for a given compaction channel.

capacity

The maximum number of items the channel can hold (lowest priority item is removed to make room for new items). Defaults to 9999.

concurrency

The maximum number of jobs that can run concurrently in this channel. Defaults to 1.

There are also several settings that collectively control whether a channel will enqueue a file for compaction and how it prioritizes files within its queue:

max_priority

Each item must have a priority lower than this to be enqueued. Defaults to infinity.

max_size

The item must be no larger than this many bytes in length to be enqueued. Defaults to infinity.

min_priority

The item must have a priority at least this high to be enqueued. Defaults to 5.0 for ratio and 16 MB for slack.

min_changes

The minimum number of changes since last compaction before the item will be enqueued. Defaults to 0. Currently only works for databases.

min_size

The item must be at least this many bytes in length to be enqueued. Defaults to 1mb (1048576 bytes).

priority

The method used to calculate priority. Can be ratio (calculated as sizes.file/sizes.active) or slack (calculated as sizes.file - sizes.active). Defaults to ratio.