Отслеживание причины «слишком большого количества открытых файлов» в OpenNMS - PullRequest
Новая
       32

Отслеживание причины «слишком большого количества открытых файлов» в OpenNMS

0 голосов
/ 05 октября 2018

Недавно у нашего OpenNMS GUI возникли проблемы с отзывчивостью.Симптомы включали в себя типичную страницу ошибки «OpenNMS обнаружила ошибку, которую он не знает, как ее обработать» при доступе, например, к странице «Все узлы», и когда я смотрел сверху на сервере, он показал javaпроцесс занимает много процессора.Проблема с отзывчивостью также повлияла на способность OpenNMS правильно опрашивать сервисы, которые он отслеживает, и поэтому у меня было много ложных ошибок «неработающего сервиса».

Опрос ICMP, похоже, не затронут, ноСервисный опрос (HTTP, SSH, SNMP и т. д.) определенно есть.Я получаю много событий сбоя в журналах с объяснением «Слишком много открытых файлов».

Кто-нибудь знает, что означает «слишком много открытых файлов» и как я могу найти причину проблемы?Я не уверен, с чего начать.

Спасибо.

Ответы [ 2 ]

0 голосов
/ 01 ноября 2018

ооо это то, с чем мне пришлось столкнуться, прежде чем тоже проверять файл opennms.conf в / opt / opennms / etc, в этом файле должен быть установлен предел MAXFILEDESCRIPTOR для opennms, который вы можете увеличить, это поможет вам избежать этой проблемы, но так какэто происходит из-за того, что процессы OpenNMS пытаются открыть больше файлов, чем установленный лимит, возникает эта проблема, или это то, что я узнал из моей встречи с этой проблемой.

Вы можете дополнительно посмотреть в / opt / opennms / logs /и проверьте output.log и manager.log. В основном output.log должен содержать информацию о том, почему это происходит

. Вы также можете увеличить детализацию этих журналов в / opt / opennms / logs, изменив WARN на DEBUG в log4j2..xml в / opt / opennms / etc /

Это должно дать вам полное представление о том, что может быть причиной этой проблемы.

Надеюсь, это поможет.

0 голосов
/ 26 октября 2018

Значения по умолчанию для мягких и жестких ограничений можно проверить с помощью 

ulimit -a
ulimit -a -H

Это значение для каждого пользователя, и каждый новый процесс наследует эти ограничения.OpenNMS изменяет жесткое ограничение во время запуска с помощью сценария инициализации по умолчанию и изменяется на 

ulimit -n 20480

Если вы запускаете OpenNMS, вы можете увидеть ограничения для JVM OpenNMS с помощью 

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

. Вы можетепосмотрите, сколько файловых дескрипторов выделено OpenNMS: 

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

Если вы используете lsof с идентификатором процесса OpenNMS, вы увидите большее число, чем в /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

В надежде, что это поможет исследовать проблемы с дескриптором файла.

...