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。

如果没有任何配置,CouchDB将把IO的所有类排队。这个默认.iniCouchDB附带的配置文件为每个交互式IO类激活一个旁路,只有后台IO进入队列系统:

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

3.9.1. 建议

默认配置可防止后台操作(如压缩操作中断交互操作的延迟)产生过多的IO,同时最大化用于这些交互请求的总IO吞吐量。在某些情况下,此配置可能是次优配置:

  • 管理员可能希望将整个IO带宽的较大一部分用于压缩,以便在传入的写入负载之前保持领先。在这种情况下,可能需要禁用旁路 write (帮助数据库压缩)和/或 view_update (以帮助压缩视图索引)然后增加 ratio 给压缩一个更高的优先级。
  • 如果服务器上有大量视图,而这些视图不需要及时更新,则可以通过删除 view_update 为了优化常规文档读写操作的延迟,并在较安静的时间段构建视图。