3.7. 压实¶

3.7.1. 数据库压缩选项¶

[database_compaction]¶

doc_buffer_size¶

指定复制缓冲区的最大大小（以字节为单位）：

[database_compaction]
doc_buffer_size = 524288

checkpoint_after¶

在将指定的字节数成功复制到压缩数据库后触发检查点：

[database_compaction]
checkpoint_after = 5242880

3.7.2. 查看压缩选项¶

[view_compaction]¶

keyvalue_buffer_size¶

指定压缩期间使用的最大复制缓冲区大小（以字节为单位）：：

[view_compaction]
keyvalue_buffer_size = 2097152

3.7.3. 压缩守护程序¶

CouchDB附带了一个自动的、事件驱动的后台进程，内部称为“smoosh”，它不断地重新排列每个节点上的数据库和辅助索引文件的优先级，并根据以下参数自动压缩将恢复最大可用空间的文件。

[smoosh]¶

db_channels¶: 以逗号分隔的通道列表，这些通道在更新数据库文件时发送这些文件的名称。每个通道都可以选择是否对数据库进行排队以进行压缩；一旦某个通道已将数据库排入队列，则列表中没有其他通道有机会这样做。

view_channels¶: 以逗号分隔的通道列表，这些通道在更新辅助索引文件时发送这些文件的名称。每个通道都可以选择是否将索引排队以进行压缩；一旦一个通道将索引排入队列，列表中的其他通道将不会有机会这样做。

staleness¶: 在重新计算之前，个人的（昂贵的）优先级计算可能过期的分钟数。默认为5。

cleanup_index_files¶: 如果设置为true，压缩守护进程将删除不再与任何设计文档关联的索引文件。默认为 false 而且可能不应该更改，除非节点的磁盘空间不足，并且只有在考虑到其后果之后。

wait_secs¶: 通道在开始压缩之前等待的时间，以便有时间观察系统并对首先压缩的内容做出更明智的决定。从默认值30秒几乎没有变化。

[smoosh.<channel>]¶

以下设置控制给定压缩通道的资源分配。

capacity¶

频道可以容纳的最大项目数（移除优先级最低的项目以腾出空间给新项目）。默认为9999。

concurrency¶

此通道中可并发运行的最大作业数。默认为1。

还有几个设置共同控制通道是否将文件排队进行压缩以及如何在其队列中对文件进行优先排序：

max_priority¶

每个项目的优先级必须低于此优先级才能排队。默认为无穷大。

max_size¶

项的长度必须不超过此字节数才能排队。默认为无穷大。

min_priority¶

该项必须具有至少此高的优先级才能排队。默认值为5.0（比率），16 MB（松弛）。

min_changes¶

自上次压缩后在将项排入队列之前所做的最小更改数。默认为0。目前只适用于数据库。

min_size¶

该项的长度必须至少达到此字节才能排队。默认为1mb（1048576字节）。

priority¶

用于计算优先级的方法。可以是比率(计算方式为 sizes.file/sizes.active )或松弛(计算方式为 sizes.file - sizes.active )。默认为比率。