【发布时间】：2020-02-03 19:24:52
【问题描述】：
如果我们定义最大打开文件数为 300，并且如果 .sst 文件的数量超过，我假设缓存中的文件将被驱逐，但是如果要访问这些被驱逐的文件中的数据，是否会重新加载它或该文件永远丢失？
https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide
【问题讨论】：
标签： apache-kafka-streams rocksdb
【发布时间】：2020-02-03 19:24:52
【问题描述】：
来自您发布的链接：
max_open_files -- RocksDB 将所有文件描述符保存在表缓存中。如果文件描述符的数量超过 max_open_files，则某些文件将从表缓存中逐出并关闭它们的文件描述符。这意味着每次读取都必须通过表缓存来查找所需的文件。将 max_open_files 设置为 -1 以始终保持所有文件打开，从而避免昂贵的表缓存调用。
这只是意味着如果超过打开文件的数量，一些文件将被关闭。如果你想访问一个关闭的文件，相应的文件将被重新打开（可能之前，另一个文件会被关闭）。
因此，配置不是关于创建/删除文件，而是关于要保持并行打开多少文件。
【讨论】：
-
我已经在链接docs.confluent.io/current/streams/developer-guide/… 之后将此选项设置为 1024，但是当我计算打开的 sst 文件的数量时，它仍然在超过 10k 个打开的 sst 文件中。还有其他需要并行配置的吗？我在单台机器上有 5 个实例配置为使用 4 个线程，这可能是原因吗？另请注意，Stream 应用程序创建 8 个全局表
-
嗯，
max_open_files适用于每个商店；如果您有 8 个 GKT，则您有 8 个商店，因此您允许打开 8 * 1024 个文件。不是 RocksDB 专家；也许还有其他打开的文件不计入限制？ -
对我来说，RocksDB 只是返回一个错误：
Too many open files，这就是故事的结局。 -
@Linas 也可能是您遇到的操作系统限制...
-
是的。这是
ulimit -n的限制。默认情况下，rocks 不会检查getrlimit(RLIMIT_NOFILE)，并且会愉快地打开超过系统允许的文件，因此读取失败并忽略写入。删除迭代器失败会导致 Rocks 大量创建*.sst文件，这将很快超过系统磁盘和 RAM 资源。