RSS / VSS перестают работать до тех пор, пока не закончится память и не произойдет своп на машинах - PullRequest
Новая
       22

RSS / VSS перестают работать до тех пор, пока не закончится память и не произойдет своп на машинах

0 голосов
/ 18 августа 2010

У нас есть сервер weblogic 9.2 с Java1.5.0.16 на RHEL5.3, на котором мы развертываем веб-службу и систему управления контентом Alfresco.

Мы работали нормально в течение ~ 3 летHP-UX i11.23 и месяц назад мы перешли на Linux RH5.3 и время от времени (это происходило 3 раза) мы замечали, что процесс начинает использовать все больше и больше памяти до тех пор, пока вся память и не поменяться местами на машинезаканчивается.

Процесс по-прежнему работает нормально, и все файлы журнала выглядят нормально (как будто ничего не произошло), включая журнал GC. 

Glance for process ID 25450:

B0000A Glance C.04.70.000 06:54:05 supra2 x86_64 Current Avg High
CPU Util SU | 2% 2% 2%
Disk Util D D | 97% 97% 97%
Mem Util U U | 98% 98% 98%
Swap Util U U | 60% 60% 60%
Resources PID: 25450, java PPID: 25394 euid: 664 User:afspr04
CPU Usage (util): 5.40 Total RSS : 40.6gb
User CPU : 3.60 Text VSS : 56kb
System CPU : 1.80 Data VSS : 66.1gb
Priority : 15 Stack VSS : 2.0mb
Nice Value : 0 Total VSS : 66.5gb
Blocked On : SLEEP
Major Faults : 235
Minor Faults : 164
Processor : 1
Argv1: weblogic.Server
Cmd : /opt/java1.5.0_16/bin/java -Dweblogic.Name=dmcmsserver -Doracle.net.tns_admin=/etc -server -javaagent:/opt/MercuryDiagn
ostics/JavaAgent/DiagnosticsAgent/lib/probeagent.jar -Dprobe.id=supra2_afspr04_dmcms_ear_p4 -Dprobe.group=CMS_SERVER -D
points.file.name=/opt/MercuryDiagnostics/JavaAgent/DiagnosticsAgent/etc/supra2_afspr04_dmcms_ear_p4 -Dcom.wily.introsco
pe.agent.agentName=DMCMS -Xms7g -Xmx7g -XX:PermSize=256m -XX:MaxPermSize=256m -XX:NewSize=1792m -XX:MaxNewSize=1792m -X
X:SurvivorRatio=4 -XX:TargetSurvivorRatio=90 -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xnoclassg
c -Xloggc:logs/gc.log -Doracle.net.tns_admin=/etc -Dweblogic.Stderr=/app/afspr04/dmcms_ear_p4/dmcmsdomain/logs/online.l
og -Dweblogic.Stdout=/app/afspr04/dmcms_ear_p4/dmcmsdomain/logs/online.log -Damdocs.system.home=/app/afspr04/dmcms_ear_
p4/properties/jesi -Damdocs.messageHandling.home=/app/afspr04/dmcms_ear_p4/properties/jesi -Djesi.config.loader=amdocs.
ecommerce.esi.utils.config.InterfaceConfigXPathLoader -Damdocs.uams.config.resource=config/mvc/ldap ...

pmap показывает большое распределение в виде анонимного pmap (отсортировано побольшой раз): 

25450: /opt/java1.5.0_16/bin/java -Dweblogic.Name=dmcmsserver -Doracle.net.tns_admin=/etc -server -javaagent:/opt/MercuryDiagnostics/JavaAgent/DiagnosticsAgent/lib/probeagent.jar -Dprobe.id=supra2_afspr04_dmcms_ear_p4 -Dprobe.group=CMS_SERVER -Dpoints.file.name=/opt/MercuryDiagnostics/JavaAgent/DiagnosticsAgent/etc/supra2_afspr04_dmcms_ear_p4 -Dcom.wily.introscope.agent.agentName=DMCMS -Xms7g -Xmx7g -XX:PermSize=256m -XX:MaxPermSize=256m -XX:NewSize=1792m -XX:MaxNewSize=1792m -XX:SurvivorRatio=4 -XX:TargetSurvivo
00002ab0f8000000    10518548    rwx--   [anon]
00002ab798009000    8388612 rwx--   [anon]
000000005fcce000    8038976 rwx--   [anon]
00002aac7aab0000    7602176 rwx--   [anon]
00002aaf74000000    5259284 rwx--   [anon]
00002ab688000000    4194308 rwx--   [anon]
00002aae4b930000    1684124 rwx--   [anon]
00002aab80000000    1314836 rwx--   [anon]
00002aab20000000    655376  rwx--   [anon]
00002aac28000000    532488  rwx--   [anon]
00002aac50000000    524292  rwx--   [anon]
00002aaaec000000    327696  rwx--   [anon]
00002aaad8000000    131088  rwx--   [anon]
00002ab658000000    131060  rwx--   [anon]
00002ab0dc000000    131044  rwx--   [anon]
00002aaacc2f5000    114708  rwx--   [anon]
...
total 69733292K

Кто-нибудь сталкивался с чем-то похожим?

Спасибо, Оз

Ответы [ 2 ]

0 голосов
/ 03 февраля 2012

У нас есть такие же проблемы здесь с другой ОС (Sun Solaris 10 - 32bit), но я вижу общую точку зрения: Introscope.

Мы подозревали, что он слишком много выделяет памяти (утечка памяти?), поскольку она использует собственную библиотеку (* .so, доступ к которой осуществляется через JNI).

Чтобы понять мою точку зрения, в этом случае мне необходимо кое-что прояснить в отношении памяти процесса JVM: всей памятиПроцесс Java разделен на две разные части, нативную и Java.

Память для части Java (которая управляется сборщиком мусора) может контролироваться с помощью стандартного API JVM.Просто помните, что в Java вы можете контролировать только эту часть памяти процесса JVM.Он содержит кучу (eden & 2 оставшихся в живых), oldgen, permgen.Эта часть памяти, как правило, самая большая, поэтому есть способы ее мониторинга, а для остальных ее нет.

Остальная часть памяти процесса, нативная часть, отличается.Он состоит из сетевых сокетов / буферов, файловых дескрипторов / буферов, фактических структур данных и буферов GC, собственных буферов библиотек, собственного кода, скомпилированного JIT-компилятором, и некоторых других внутренних специфичных для JVM вещей.Существует также исполняемый код JVM и нативные библиотеки.Обычно в этой части нет стандартного способа (часто совсем нет), за исключением использования отладчика.

Спросив C & A о собственной библиотеке Wily / Introscope, они объяснили нам, что:

  • динамически распределяет память;
  • нет способа ограничить потребление памяти;
  • нет способа предсказать потребление памяти;
  • этоиспользуется Wily только для сбора конкретных показателей базовой системы (например, флагов ОС, загрузки процессора, общего объема свободной памяти, количества процессов и т. д.), поскольку Introscope использует API-интерфейс агента Java для всего остального.

Для 99% приложений «нативная» часть памяти (не-Java-часть) ничтожна по сравнению с Java-частью.

Но здесь, когда в нашу игру играет Introscope, вещистановятся другими, так как нативная часть может расти как угодно большой и использовать пространство памяти процесса до пределов.

Мы пришли к выводу, что эти системные значения не очень интересныжаль для нас - и я думаю, что это относится ко многим из вас, так как есть другие способы получить их: mem, free, top, taskmanager, ... - поэтому мы решили удалить его.Просто.

Я считаю, что это лучший вариант.

Попробуйте и скажите нам, если это решило ваши проблемы с памятью.

0 голосов
/ 18 августа 2010

Какой ЦП / ОЗУ сервера вы используете? Вам следует обратиться к матрице совместимости RHEL для WLS 9.2 и убедиться, что конфигурация JDK / CPU является поддерживаемой комбинацией. Кроме того, поскольку вы, возможно, захотите рассматривать JRockit как свою JVM, если это вариант для вас. Наконец, также попробуйте уменьшить максимальное пространство кучи (-Xmx и -Xms) и посмотреть, является ли сервер более стабильным.

...