Question

最近，我们的OpenNMS GUI出现了响应问题。症状包括访问时的通用“ OpenNMS遇到了一个错误，它不知道如何处理”错误页面，例如，“所有节点”页面，并且当我在服务器顶部查看时，它显示了Java进程占用大量CPU。响应性问题也影响了OpenNMS正确轮询其监视的服务的能力，因此我遇到了很多错误的“服务关闭”错误。

ICMP轮询似乎没有受到影响，但是服务轮询（HTTP，SSH，SNMP等）肯定会受到影响。我在日志中收到很多中断事件，解释为“打开的文件太多”。

有人知道“打开的文件太多”是什么意思，以及如何找到导致问题的原因吗？我不确定从哪里开始。

谢谢。

Answer 1

可以通过以下方式检查软限制和硬限制的默认值：

ulimit -a
ulimit -a -H

该值为每个用户，每个新进程都继承这些限制。 OpenNMS在启动期间使用默认的初始化脚本更改硬限制，并使用

进行更改

ulimit -n 20480

如果启动OpenNMS，则可以通过以下方式查看OpenNMS JVM的限制

cat /proc/$(cat /var/run/opennms.pid)/limits

您可以看到OpenNMS分配了多少文件描述符：

ls -l /proc/$(cat /var/run/opennms.pid)/fd | wc -l

如果您将lsof与OpenNMS的进程ID一起使用，则会看到比/proc/pid/fd中更大的数字

lsof -p $(cat /var/run/opennms.pid) | wc -l

原因是列出了内存映射的.so文件，这些文件不计入配置的限制，并以lsof列出。

lsof | grep $(cat /var/run/opennms.pid) | wc -l

如果要查看使用了多少个文件系统句柄，可以运行：

cat /proc/sys/fs/file-nr

4128    0   262144

您可以看到三个值：

number of allocated file handles: 4128
number of used file handles:      0
maximum number of file handles:   262144

希望这有助于调查您的文件处理问题。

Answer 2

哦，这是我不得不面对的事情，在检查/ opt / opennms / etc中的opennms.conf文件之前，该文件应该为opennms设置MAXFILEDESCRIPTOR LIMIT，您可以增加它，这将帮助您避免此问题，但是由于之所以发生这种情况，是因为OpenNMS进程试图打开的文件超出了其设置的限制，或者是我从遇到此问题时发现的结果。

您可以进一步调查 / opt / opennms / logs /并检查output.log和manager.log主要是output.log应该向您提供有关发生这种情况的信息

您还可以通过将/ opt / opennms / etc /

中log4j2.xml中的WARN更改为DEBUG来增加/ opt / opennms / logs中这些日志的详细程度

这应该使您对导致此问题的原因有深刻的了解。

希望这会有所帮助。

跟踪OpenNMS中“打开的文件过多”的原因

2 个答案: