如何避免arangodb集合锁 [英] How to avoid arangodb collection locks

问题描述

我启用了跟踪，我看到以下消息在一秒钟内打印了 10k 次.

I have trace enabled and I see following message being printed out like 10k times with in a second.

2016-03-12T18:14:56Z [31136] TRACE [C:\b\ArangoDB-2.8.4\arangod\Wal\CollectorThread.cpp:750] wal 收集器无法获取集合 '39659811 的写锁'

2016-03-12T18:14:56Z [31136] TRACE [C:\b\ArangoDB-2.8.4\arangod\Wal\CollectorThread.cpp:750] wal collector couldn't acquire write lock for collection '39659811'

以下是该系列的数字.

类型计数大小信息数据文件 57 1.79 GB期刊 1 32 MB
压实机 0 0 B形状文件 0 0 B索引 3 890.2 MB
类型计数信息形状 239属性 77
未收集的 221145
参考文献1
类型计数大小删除信息活着 4398864 930.54 MB -
死 4484771 918.31 MB 0

Type Count Size Info Datafiles 57 1.79 GB Journals 1 32 MB
Compactors 0 0 B Shape files 0 0 B Indexes 3 890.2 MB
Type Count Info Shapes 239 Attributes 77
Uncollected 221145
References 1
Type Count Size Deletion Info Alive 4398864 930.54 MB -
Dead 4484771 918.31 MB 0

推荐答案

ArangoDB 有两种用于集合的数据文件:

ArangoDB has two kinds of datafiles for collections:

• WAL 文件(预写日志)；如果创建了新的(版本的-)文档，这就是它们直接去的地方，以确保尽可能快地将数据持久地写入磁盘.此文件呈线性增长.
• 收集文件；每个集合一个；这里我们有(旧的)永久数据.

因此，如果您插入或更新文档，它们会立即在滚动的 WAL 文件中结束.这很好，因为旋转磁盘不喜欢搜索；所以突发被线性写入一个 WAL 文件，无论它们在哪个集合中.磁盘可以通过将写操作分组到物理狭窄的区域来有效地进行写突发，并且不需要在文件之间跳转(物理位置在磁盘).

So if you insert or update documents, they instantly end up in the rolling WAL-files. This is good since spinning disks don't like seeks; so the bursts are written linear into one WAL-file, regardless of which collection they're in. Disks can effectively do their write bursts by grouping write operations in physically narrow areas, and don't need to jump between files (physical places on disk).

文档由引用它们的索引管理，无论是在数据文件中还是在 WAL 文件中.它也可以在 ArangoDB 重新启动时完美运行.

Documents are managed by indices that reference them, be they in the data file or the WAL-files. It will also work flawlessly across ArangoDB restarts.

现在到您要问的 WAL-Collector 线程.这个线程在这里进行文档从 wal 文件到它们各自的集合文件的转换.由于您的查询可能正在其他线程中处理这些文档，因此它不能移动它们而不能确保它们处于空闲状态.因此它需要尝试获取它打算为其迁移文档的集合锁.这可能并不总是奏效，因为这在 ArangoDB 的开发过程中可能很有趣，然后它会为此写入跟踪日志条目.但是，迟早它应该有时间这样做，并且一旦 WAL 文件的所有文档都迁移完毕，就可以删除该文件.

Now to the WAL-Collector thread you're asking about. This thread is here to do the transitions of documents from the wal files into their respective collection files. Since your queries may be working with these documents in other threads, it mustn't move them while it can't make shure they're idle. Therefore it needs to try to get the collection lock for which it intends to migrate the documents for. This may not always work out, and as this may be interesting during the development of ArangoDB it then writes a trace log entry for that. However, sooner or later it should find the time to do so, and once all documents of a WAL-file are migrated, the file can be dropped.

由于这是 ArangoDB 的常规业务 - TL;DR:除非您停止使用跟踪日志级别，否则您无法避免这些消息，并且只要 WAL 文件迟早被清除，您就不必担心.

Since this is regular business of ArangoDB - TL;DR: You can't avoid these messages unless you stop using the trace loglevel and you don't need to wory about it as long as the WAL-files are cleaned up sooner or later.

这篇关于如何避免arangodb集合锁的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！