Solr文件描述符计数

Question

我有一个Apache Solr 4.2.1实例，它有4个核心总大小（625MB + 30MB + 20GB + 300MB）21 GB。

它运行在4核CPU，16GB RAM，120GB HD，CentOS专用机器上。

第一核心每天完全进口一次。

第二核心每两小时完全导入一次。

第三核心是每两小时进口三角洲。

4rth核心每两小时完全进口一次。

服务器也有大量的查询（搜索和创建，更新和删除文档）。

每个核心都有maxDocs：100和maxTime：15000表示autoCommint，maxTime：1000表示autoSoftCommit。

系统用法是：

1. 大约97％的14.96 GB物理内存

2. 0MB交换空间

3. 4096个文件描述符计数的约94％

4. 从1.21GB的JVM-Memory的60％到90％。

当我重新启动机器时，文件描述符计数下降到接近0，然后在一周左右的时间内稳定地达到上述值。

因此，总而言之，我的问题是：

1. 4096文件描述符数量的94％是否正常？

2. 如何增加最大文件描述符数？

3. 如何计算最大和使用的文件描述符计数的理论最佳值。

4. 文件描述符计数是否达到100？如果是，服务器将崩溃？或者它会使它自身低于100％并且它应该起作用吗？

事先非常感谢！

Answer 1

1. 不确定。
2. ulimit -n <number>。见Increasing ulimit on CentOS。
3. 确实没有 - 根据很多因素需要多少，例如你的合并因子（如果你有许多文件，打开文件的数量会很大好吧 - 对于不完全导入的索引尤其如此。检查数据目录中的文件数量，如果相同的索引变得非常分散且具有大的合并因子，则发出优化），搜索者数量，在同一台服务器上运行的其他软件等。
4. 可以。是（或者至少它不能正常运行，因为它无法打开任何新文件）。在实践中，您将收到一条消息，指出无法打开包含消息的文件＆＃34;打开的文件太多＆＃34;。

Answer 2

因此，文件描述符计数（FDC）的问题以及对于不断增加的FDC更精确的问题是我每次更新后都会提交！

我注意到Solr没有删除旧的事务日志。因此，在一周的FDC最大化之后，我被迫重新启动。

我在每次更新后都停止了提交，现在我的Solr统计信息是：

1. 14.96 GB物理内存的55％左右
2. 0MB交换空间
3. 4096文件描述符计数的4％左右
4. 从1.21GB的JVM-Memory的60％到80％。

此外，旧的交易日志会被自动提交（软和硬）删除，Solr也没有更多的性能问题！

所以，正如本文中指出的那样：

Understanding Transaction Logs, Soft Commit and Commit in SolrCloud

“要非常小心地从客户那里下来！事实上，不要这样做。”