Я новичок в AIX и системном мониторинге. Фактически наше приложение в настоящее время работает на jboss 5.1 в AIX 5.3. Пожалуйста, проверьте конфигурацию и системные настройки ниже.
oslevel -g)svmon -G)lsps -s)prtconf | grep Processor)java -fullversion)-d64 -Xms2g -Xmx4g -XX:MaxPermSize=1024m Иногда мы наблюдаем очень странное поведение в JBoss это зависает без каких-либо журналов ошибок. Также журнал сервера останавливается без дальнейшей трассировки. Также мы не можем получить дамп потока (kill -3) и его не генерировать в этот момент. (kill -3 xxxxx работает в нормальных условиях) Единственная доступная для нас опция - это перезапустить сервер jboss, и он покажет все сообщения, которые были в очередях во время процесса замораживания после перезапуска.
Мы пытаемся настроить некоторые параметры в JBoss hornetq, хотя проблема была там. Hornetq застрял по умолчанию. Но нам не повезло, и мы также не можем изолировать проблему в какой-либо точке. Мы смотрим на такой инструмент, как nmon, для наблюдения за этим, но не можем сказать, что он достаточно хорош для этого.
Укажите, пожалуйста, что-нибудь для исследования этой проблемы.
Спасибо
1. Проверьте полные заполнители
Вам нужно проверить, активирован ли fullcore на вашем AIX:
lsattr -Elsys0 | grep full
Чтобы включить fullcore:
chdev -l sys0 -a fullcore=true
2. Проверьте лимиты
Пределы размера и ядра должны быть установлены на unlimited.
ulimit -c unlimited
ulimit -f unlimited
Первое, на что нужно обратить внимание, это исчерпание пространства кучи. Включите подробную сборку мусора, добавив следующие параметры в параметры Java.
-verbose:gc
Просмотрите результат вручную или проанализируйте его с помощью http://www.tagtraum.com/gcviewer.html.
Насколько я помню, AIX JDK сильно отличается от Sun JDK, включая стратегию сборки мусора, поэтому нужно быть осторожным при чтении JDK.
В исправном приложении вы увидите увеличение используемого пространства кучи, а затем, когда будет выполняться полный сборщик мусора, используемое пространство должно значительно сократиться. Это будет повторяться на протяжении всего срока службы приложения.
В нездоровом приложении потеря памяти после полного GC будет каждый раз немного меньше, так что со временем используемое пространство кучи будет медленно подниматься все выше и выше, пока не станет больше доступной памяти. На этом этапе JDK обычно перестает отвечать, поскольку он постоянно запускает сборщик мусора, пытаясь освободить память.
Если это происходит, вам придется взглянуть на свое веб-приложение. Разработчики нередко кэшируют объекты в памяти, но не используют ограничение на количество объектов.
НАКОНЕЧНИК: Устанавливать -Xms того же размера, что и -Xmx. Выделение памяти из операционной системы для кучи - дорогостоящая операция. В серверной среде это не имеет особого смысла, поскольку вам всегда требуется достаточно реальной памяти для кучи.