Arangodb：没有可用的文件描述符

Question

在 ArangoDB3 几年没有出现任何问题之后，突然，我遇到了以下形式的 AQL IO 错误

[HTTP 500][ERR 1305] AQL: IO error: While open a file for random read: /ssd1/arangodb3/engine-rocksdb/22850496.sst: No file descriptors available (while finalizing)

这是在执行表单插入时

insert { id: "foo", junk: [ 1, 2, 3 ] } in bar

这是在运行填充新数据库的冗长操作后发生的。

查看

syslog

，我看到以下内容（时间戳等，为了可读性而省略）：

ERROR [fae2c] {rocksdb} RocksDB encountered a background error during a compaction operation: IO error: While open a file for random read: /ssd1/arangodb3/engine-rocksdb/22850496.sst: No file descriptors available; The database will be put in read-only mode, and subsequent write errors are likely. It is advised to shut down this instance, resolve the error offline and then restart it.
ERROR [be9ea] {rocksdb} rocksdb: [db/db_impl/db_impl_compaction_flush.cc:2922] Waiting after background compaction error: IO error: While open a file for random read: /ssd1/arangodb3/engine-rocksdb/22850496.sst: No file descriptors available, Accumulated background error counts: 1
WARNING [afa17] {engines} could not sync metadata for collection 'OpenAlex_20240502/works'
WARNING [a3d0c] {engines} background settings sync failed: IO error: While open a file for random read: /ssd1/arangodb3/engine-rocksdb/22850496.sst: No file descriptors available
WARNING [afa17] {engines} could not sync metadata for collection 'OpenAlex_20240502/publishers'

上面的第一条消息似乎表明了一些事情，但我不确定是什么。

有问题的文件

/ssd1/arangodb3/engine-rocksdb/22850496.sst

不存在，这将是问题的明显根源，但我不确定如何解决它。

重新启动 Arango DB 和系统并不能解决问题。

文件系统上有足够的空间

/dev/nvme0n1p1                          7.3T  4.6T  2.8T  63% /ssd1

所以这不是问题。

arangodb --version

报道

Arango DB Version 0.18.2, build 3518b68, Go go1.21.5

arangosh --version

报道

3.11.8

architecture: 64bit
arm: false
asan: false
assertions: false
avx: true
avx2: false
boost-version: 1.78.0
build-date: 2024-02-22 14:43:37
build-repository: refs/tags/v3.11.8 eb715d099fb
compiler: gcc [11.2.1 20220219]
coverage: false
cplusplus: 202002
curl-version: none
debug: false
endianness: little
failure-tests: false
fd-client-event-handler: poll
fd-setsize: 1024
full-version-string: ArangoDB 3.11.8 [linux] 64bit, using jemalloc, build refs/tags/v3.11.8 eb715d099fb, VPack 0.2.1, RocksDB 7.2.0, ICU 64.2, V8 7.9.317, OpenSSL 3.0.13 30 Jan 2024
icu-version: 64.2
ipo: true
iresearch-version: 1.3.0.0
jemalloc: true
libunwind: true
license: community
maintainer-mode: false
memory-profiler: true
ndebug: true
openssl-version-compile-time: OpenSSL 3.0.13 30 Jan 2024
openssl-version-run-time: OpenSSL 3.0.13 30 Jan 2024
optimization-flags: -mfxsr -mmmx -msse -msse2 -mcx16 -msahf -mpopcnt -msse3 -msse4.1 -msse4.2 -mssse3 -mpclmul -mavx -mxsave
pic: 2
pie: 2
platform: linux
reactor-type: epoll
replication2-enabled: false
rocksdb-version: 7.2.0
server-version: 3.11.8
sizeof int: 4
sizeof long: 8
sizeof void*: 8
sse42: true
tsan: false
unaligned-access: true
v8-version: 7.9.317
vpack-version: 0.2.1
zlib-version: 1.2.13

我运行的是 Ubuntu 23.10

Linux servername 6.5.0-28-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 28 23:46:48 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

我尝试重新安装 Arango DB，但没有可用。我已从检查点重新启动应用程序，但它现在立即持续失败。 即使像上面这样简单的插入也会引发相同的错误。

该应用程序是用 python 编写的，是多线程的，使用

multiprocessing

模块，有 64 个线程/进程都在执行上传。

我在另一个系统上运行相同的代码，并且它很高兴运行完成，所以我很困惑这里可能会出现什么问题。

Answer 1

首先，我要提到的是，我设法通过删除几个相当大但未使用的数据库并从头开始重新运行应用程序的权宜之计来运行应用程序。 成功！尽管更多的是运气而不是智力，正如我在下面指出的那样。

正如评论者所指出的，我相信文件描述符限制是罪魁祸首 - 但是，就像灯柱下的醉汉一样，我在光线好的地方寻找我的钥匙，而不是我实际上掉落钥匙的地方。

今天早上我终于震惊地仔细查看了

/lib/systemd/system/arangodb3.service

中的ArangoDB启动文件，它揭示了以下内容：

# system limits
LimitNOFILE=131072
LimitNPROC=131072
TasksMax=131072

这在我昏暗的小大脑中产生了一点啊哈！的时刻。

这让我查看了删除之前保存的备份 无关数据库：

myobfuscatedhost:/ssd1/arangodb3/engine-rocksdb# ls -1 | grep sst | wc -l
130878

你瞧，这些数字相当接近。

看来，通过使用

lsof

，确实，

engine-rocksdb

目录中的每个文件都已打开。

因此，提高上述限制应该可以解决问题。

我说应该，因为我还没有完全检验我的假设，因为正如我在开头段落中提到的，我通过删除多余的数据集并为自己留出足够的空间来完成手头的任务，暂时解决了问题。

我会增加

/lib/systemd/system/arangodb3.service

的限制，祈祷一切顺利。

感谢所有最终设法将答案敲入我厚实头脑中的人。