CouchDB延迟构建索引（Windows Server 2008 R2上的CouchDB 1.5.0）

Question

据我所知，CouchDB会根据索引文件的名称散列每个设计文档的来源。每当我更改源代码时，都需要重建索引。 CouchDB在第一次请求文档时执行此操作。

我期待发生并希望发生的事情

每次我更改设计文档时，对视图的第一次调用将比平时花费更长的时间并且可能会超时。该指数将继续建立。完成此操作后，视图将仅处理更改并且速度非常快。

实际发生的事情

1. 首次运行修改后的视图时，我在状态窗口中看到进程，慢慢达到100％。这大约需要2个小时。在此期间，所有CPU都得到了充分利用。
2. 一旦过程达到99％，它会在那里停留约一个小时然后消失。 CPU利用率下降到只有一个CPU。
3. 当进程消失时，视图的数据文件将持续增长约半小时到一小时。 CPU利用率接近0％
4. 索引文件突然停止增加大小。

如果我在达到状态4）时再次请求视图，则3）的特征再次开始。我必须在5到50次之间重复这个过程，直到我最终可以检索视图值。

如果视图在第1阶段或第2阶段第二次被请求，那么它肯定会耗尽内存而我必须重新启动CouchDB服务。尽管我的DB在运行一个作业时很少使用超过2 GByte，并且在正常操作中超过4 GByte。

我试图调整配置设置，添加更多内存，但似乎没有任何影响。

我的问题

我是否误解了运行视图的概念或者我的设置有问题？ 如果这是预期的，有什么我可以调整以减少重新运行的次数吗？

上下文

我的文件很大（1到20 MB）。它们包含的数据结构良好，通常是网络分析报告，并且在关系数据库中可以存储为几个10k行的数据。

我的地图功能会提取这些行。它将维度返回为关键数组。键阵有时超过20列。大多数视图只有不到10列。

reduce函数将聚合（求和）具有相同键的行中的所有值。度量标准存储在字典中，可能包含不同的密钥。 reduce函数标识一个文档中缺少的键，并将这些键添加到聚合为0.

我在Windows Server 2008 R2上使用CouchDB 1.5.0，具有2CPU和8 GB内存。

使用couchjs查询服务器在javascript中编写视图。

我的设计文档通常包含多个视图，其中包含＆＃39; _lib＆＃39;视图不发出任何数据，但包含实际视图访问的详尽功能库。

Answer 1

这是一个众所周知的问题，但以防万一：如果你有数十亿字节的文档，你可以忘记减少功能。只有build-in ones才能运行得足够快。

Answer 2

可以将os_process_limit设置为超低值（1秒，样本）。通过这种方式，您可以检测哪个文档需要很长时间才能编入索引并优化地图函数以提高性能。