如果我试图截断大约4,000万个文档的大量集合,我会在arangosh中超时并且arangodb服务没有响应 . 信息:
arangosh [database_xxx]> db . [collection_yyy] .truncate();文件'/usr/share/arangodb/js/client/modules/org/arangodb/arangosh.js'中的JavaScript异常,位于104,13:[ArangoError 2001:读取错误:'tcp://127.0.0.1:8529' '读取期间超时']!抛出新的ArangoError(requestResult); ! ^ stacktrace:在ArangoCollection.truncate的Object.exports.checkRequestResult(/usr/share/arangodb/js/client/modules/org/arangodb/arangosh.js:104:13)出错(/ usr / share / arangodb / js / client / modules / org / arangodb / arango-collection.js:468:12)at:1:11
Debian Jessie上的ArangoDB 2.6.9,AWS ec2 m4.xlarge,16G RAM,SSD . 该服务没有响应 . 我怀疑它被卡住了(不仅仅是忙碌),因为它在我停止之后才能工作,删除/ var / lib / arangodb / databases /中的数据库,然后重新开始 .
我知道由于尺寸的原因,我可能会倾向于性能极限,但我猜想无论大小如何都不会失败 .
然而,在非 Cloud Windows 10,16GB RAM,SSD上,同样的动作成功了 - 过了一会儿 .
这是一个错误吗?我有一些python代码,如果有帮助,可以将虚拟数据加载到集合中 . 如果我提供更多信息,请告诉我 . 是否有助于摆弄--server.request-timeout?
在此先感谢Søren
1 回答
增加ArangoShell的
--server.request-timeout
只会增加shell在关闭空闲连接之前将使用的超时 . arangod服务器还将关闭延迟保持活动连接,这可能会更早发生 . 这是通过服务器的--server.keep-alive-timeout
设置来控制的 .然而,增加两者并没有多大帮助 . 实际问题似乎是
truncate()
操作本身 . 是的,它可能非常昂贵 .truncate()
是一个事务操作,因此它会将它删除的每个文档的删除标记写入服务器的预写日志 . 它还将缓冲内存中的每个删除,以便在失败时回滚操作 .比
truncate()
更少侵入性的操作是删除集合并重新创建它 . 这应该非常快 . 但是,如果它们在删除之前存在,则需要手动重新创建/恢复集合的索引和特殊设置 .对于文档集合,可以这样实现: