3.9. IO 队列

CouchDB 具有一个内部子系统，可以优先处理与某些操作类别相关的 IO。可以配置此子系统，以根据下面描述的设置限制分配给后台操作（如内部复制和压缩）的资源。

[ioq]

concurrency

指定队列系统将提交的并发进行中的 IO 请求的最大数量

[ioq]
concurrency = 10

ratio

当两个队列都不为空时，后台 IO 请求被选中而不是交互式 IO 请求的时间比例

[ioq]
ratio = 0.01

[ioq.bypass]

系统管理员可以选择将特定类别的 IO 直接提交到底层文件描述符或操作系统进程，完全绕过队列。安装旁路可以产生更高的吞吐量和更低的延迟，但会放弃对优先级的某些控制。以下类别得到识别

os_process

发送到外部进程（例如，couchjs）的消息。

read

满足交互式读取请求的磁盘 IO。

write

更新数据库所需的磁盘 IO。

view_update

更新视图和其他辅助索引所需的磁盘 IO。

shard_sync

由后台复制进程发出的磁盘 IO，用于修复分片副本之间的任何不一致。

compaction

由压缩作业发出的磁盘 IO。

reshard

由重新分片作业发出的磁盘 IO。

在没有任何配置的情况下，CouchDB 将对所有类别的 IO 进行排队。与 CouchDB 一起提供的 default.ini 配置文件为每个交互式 IO 类别激活了旁路，只有后台 IO 会进入队列系统

[ioq.bypass]
os_process = true
read = true
write = true
view_update = true
shard_sync = false
compaction = false
reshard = false

3.9.1. 建议

默认配置可以防止来自后台操作（如压缩）的过度 IO 扰乱交互式操作的延迟，同时最大限度地提高分配给这些交互式请求的整体 IO 吞吐量。在某些情况下，此配置可能不是最佳的

• 管理员可能希望将更大的整体 IO 带宽部分分配给压缩，以便领先于传入的写入负载。在这种情况下，可能需要禁用 write 的旁路（以帮助进行数据库压缩）和/或 view_update 的旁路（以帮助进行视图索引压缩），然后增加 ratio 以赋予压缩更高的优先级。

• 具有大量不需要完全最新的视图的服务器可能会从删除 view_update 上的旁路中获益，以优化常规文档读取和写入操作的延迟，并在较安静的时间段内构建视图。