目前我有一个用完文件描述符的弹性搜索群集，并且检查了弹性搜索设置文档页面我看到建议将机器上的文件描述符数设置为32K甚至64K 并在搜索结果上挖掘了一下我发现某些人将此限制设置为阈值甚至更高（128K或无限制）。
我得到的例外情况对文件描述符用尽非常普遍：
Caused by: org.apache.lucene.store.LockReleaseFailedException: Cannot forcefully unlock a NativeFSLock which is held by another indexer component
根据索引，碎片，副本和/或文档的数量，是否存在弹性搜索/ lucene需要的文件描述符数量的等式？甚至可以为所有弹性搜索索引提供文件数量？
我不想通过尝试和错误来设置它，并且我的情况不可能无限数量的文件描述符。
答案 0 :(得分：2)
我对弹性搜索知之甚少，但会尝试从Lucene的角度来回答这个问题。
我担心没有简单的方法可以找出你真正需要多少描述符。
首先，这取决于Directory实现（如果您使用FSDirectory.open(File)，它本身取决于底层操作系统。）
其次，它还取决于您的合并策略（可能取决于Lucene版本，除非elasticsearch覆盖它）。
最后，它甚至可以依赖于各种奇特的情况，例如垃圾收集行为（如果某些位依赖于终结器来释放资源）。在我们手动切换-d64模式之前，我们甚至有一个Lucene实例正在泄漏文件描述符。
上面说过，我建议你设置一个监控脚本，在一周左右的时间内收集一些统计数据，并提出适合你典型用法的范围。为意外情况添加一些差异。
P.S。我正在努力想象这些日子里文件描述符会成为真正问题的案例。这是C10K问题吗？你能详细说明一下吗？