3.7. Compaction¶

3.7.1. Database Compaction Options¶

[database_compaction]¶

doc_buffer_size¶

Specifies the copy buffer’s maximum size in bytes:

[database_compaction]
doc_buffer_size = 524288

checkpoint_after¶

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

[database_compaction]
checkpoint_after = 5242880

3.7.2. View Compaction Options¶

[view_compaction]¶

keyvalue_buffer_size¶

Specifies maximum copy buffer size in bytes used during compaction:

[view_compaction]
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.