在 couchdb 从 1.6.1 迁移到 2.3.1 期间，由于内存问题 couchup 实用程序需要大量时间重建视图

Posted 2023-03-15

【中文标题】在 couchdb 从 1.6.1 迁移到 2.3.1 期间，由于内存问题 couchup 实用程序需要大量时间重建视图

【英文标题】：During migration of couchdb from 1.6.1 to 2.3.1, due to memory issues couchup utility taking lot of time rebuild views

【发布时间】：2021-03-26 20:43:25

【问题描述】：

在我将 couchdb 从 1.6.1 迁移到 2.3.1 期间，couchup 实用程序需要花费大量时间来重建视图。 couchup 实用程序存在内存问题。数据库的大小在 500 GB 范围内。它需要永远。已经快5到6天了，还没有完成。有什么办法可以加快速度吗？

尝试进行复制时，couchup 运行 2-3 分钟后，couchdb 因内存泄漏问题而死，然后又重新启动。复制大约需要 10 天。对于复制，它显示进度条，但对于重建视图，它不显示进度条。不知道做了多少。

couchdb 安装在 RHEL Linux 服务器中。

【参考方案1】：

减少积压增长：

当 couchup 遇到需要超过 5 秒才能重建的视图时，couchup 将继续调用其他视图 url，从而触发它们的重建。一旦运行了许多长时间运行的视图重建，即使是更短的重建也将需要至少 5 秒，从而导致大量积压。如果单个数据库很大或者（map/reduce 功能非常低效），最好将超时设置为 5 分钟。如果您看到不止一对：

 Timeout, view is processing. Moving on.

消息可能是时候终止 couchup 并将超时时间加倍。

观察指数增长

默认情况下view_index_dir 与数据库目录相同，因此如果数据在/var/lib/couchdb/shards 中，则/var/lib/couchdb 是配置的目录，索引存储在/var/lib/coucdh/.shards 中。您可以观察哪些索引分片文件正在创建和增长，或者将view_index_dir 移动到单独的位置以便于观察。

哪些资源快用完了？

一般可以调couchdb，一旦系统不重建所有索引等就很难说是否需要调优了。

特别是，您可能希望查找并禁用任何自动压缩。查看/proc/[couchdb proc] 中的文件以找出有效的 fd 限制以及打开文件的数量以及崩溃是否发生在特定数量的打开文件附近。由于分片，打开文件的数量通常是早期版本数量的倍数。

查看内存增长并确定它是否足够稳定以使用交换来防止问题。

【讨论】：

感谢您的回复。我尝试将超时时间设置为 5 分钟，但脚本在运行 1 分钟后仍然失败。看起来它再次遇到了性能问题。即使 CPU 和内存增加了 4 次。requests.exceptions.ConnectionError: ('Connection aborted.', error(111, 'Connection denied'))

你做了什么来确定你的内存不足？您可能会用完文件描述符等。

nocatch,os_process_error,exit_status,1,[couch_os_process,prompt,2,[file,"src/couch_os_process.erl",line,59] ,couch_query_servers,map_doc_raw,2,[file,"src/couch_query_servers.erl",line,68],couch_mrview_updater,'-map_docs/2-fun-0-',3,[file ,"src/couch_mrview_updater.erl",line,199],lists,foldl,3,[file,"lists.erl",line,1263],couch_mrview_updater,map_docs,2 ,[file,"src/couch_mrview_updater.erl",line,206]] 有时我会看到错误消息，例如内存水印高或内存用户最差

RAM 大小，db_size(shard_size,largest_doc_size) 之间的大致关系是什么？您可以尝试减少视图一次可以处理的文档数量，即：[view_updater] queue_item_cap = 100

感谢您的指导@lossleader。我在 local.ini [view_updater] min_writer_items = 10 min_writer_size = 2097152 下面放了。但仍然没有什么不同。它再次使用命令 free -g ， sar -u 5 检查内存和 cpu。内存 70% 仍然可用，CPU 80% 可用。但是当我运行 $top 命令时，对于 beam.smp 进程，它显示 CPU% 为 300%。按照建议，我创建了单独的文件夹供查看。我没有看到在视图文件夹中创建了任何文件。它看起来与内存或 CPU 无关。有2个分片