Солярис и Java требуют непрерывного очищения памяти - PullRequest
Новая
       61

Солярис и Java требуют непрерывного очищения памяти

4 голосов
/ 29 февраля 2012

Справочная информация:

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

64-битная машина SunOS 10 имеет 16 ГБ ОЗУи единственное не системное приложение, которое работает, является JVM для этого приложения.64-битная JVM работает в JBoss, что, я думаю, не имеет отношения к этому обсуждению, и максимальный размер кучи составляет 8 ГБ, что, я думаю, уместно.

В последнее время проблема заключается в том, что мы получаем различные ошибки памяти.Куча не заполнена, когда эти ошибки происходят, и ошибка запрашивает «Out of Swap Space?».Производитель хочет, чтобы мы просто увеличили объем подкачки с 2 ГБ до 4 ГБ. Это система с 16 ГБ, а приложение имеет только 8 ГБ.Мы считаем, что это будет плохая идея для производительности.

Мой вопрос:

Итак, мы обнаружили, что кэширование файлов использует всю оставшуюся свободную память дляувеличить производительность.Обычно это не проблема, но она, очевидно, фрагментирует память.Поскольку JVM Hotspot требует непрерывного пространства памяти, мы поняли, что эта фрагментация памяти приводит к использованию пространства подкачки, которое не фрагментировано.

Однако я не уверен, что понимаю взаимосвязь между фрагментацией итребование непрерывной памяти.Конечно, фрагментация просто относится к фрагментации физического барана.С виртуальной памятью вполне возможно выделить непрерывную часть оперативной памяти без поддержки непрерывной частью оперативной памяти.Другими словами, несмежный кусок физической памяти будет казаться запущенному процессу как непрерывный кусок виртуальной памяти.

Итак, я думаю, там не было ни одного предложения с предложением, но кто-нибудь знаетбольше на эту тему, а может вмешаться?Любые ссылки, которые ссылаются на эту проблему смежной памяти в 64-битных системах?

Что я нашел до сих пор:

До сих пор все ссылки, которые я нашел на «смежные»проблема памяти больше связана с тем, как виртуальное адресное пространство расположено в 32-битных адресных системах.Поскольку мы работаем с 64-битной системой (с, я думаю, 48-битной адресацией), существует много виртуального адресного пространства для выделения больших смежных блоков.

Я просматривал всеИнтернет для этой информации, но до сих пор не смог найти информацию, которую я ищу.

Обновления:

  • Чтобы было ясно, яне пытался получить ответ на вопрос, почему я получаю ошибки OOM, а скорее пытался понять взаимосвязь между, возможно, фрагментированной системной оперативной памятью и непрерывным фрагментом виртуальной памяти, необходимой для Java.
  • prstat -Z 
ZONEID    NPROC  SWAP   RSS MEMORY      TIME  CPU ZONE  
     0       75 4270M 3855M    24%  92:24:03 0.3% global
  • echo ":: memstat" |mdb -k 
Page Summary                Pages                MB  %Tot    
------------     ----------------  ----------------  ----  
Kernel                     326177              2548   16%  
ZFS File Data              980558              7660   48%  
Anon                       561287              4385   27%  
Exec and libs               12196                95    1%  
Page cache                  17849               139    1%  
Free (cachelist)             4023                31    0%  
Free (freelist)            156064              1219    8%  

Total                     2058154             16079  
Physical                  2042090             15953

  • Когда я ранее думал, что данные файла ZFS являются свободно доступной памятью, я с тех пор узнал, что этоне так, и вполне может быть причиной ошибок.

  • vmstat 5 5 

kthr      memory            page            disk          faults      cpu  
r b w   swap  free  re  mf pi po fr de sr vc vc vc --   in   sy   cs us sy id  
0 0 0 2161320 2831768 12 55 0  0  0  0  0  3  4 -0  0 1089 1320 1048  1  1 98  
0 0 0 819720 1505856 0  14  0  0  0  0  0  4  0  0  0 1189  748 1307  1  0 99  
0 0 0 819456 1505648 0   1  0  0  0  0  0  0  0  0  0 1024  729 1108  0  0 99  
0 0 0 819456 1505648 0   1  0  0  0  0  0  0  0  0  0  879  648  899  0  0 99  
0 0 0 819416 1505608 0   1  0  0  0  0  0  0  3  0  0 1000  688 1055  0  0 99

  • Эти выходные данные команды были получены, когда приложение работало в исправном состоянии.Сейчас мы отслеживаем все вышеперечисленное и записываем его на случай, если снова увидим ошибки в пространстве подкачки.

  • Ниже приведено описание того, как JVM выросла до 8 ГБ, а затем была перезапущена.В результате ZFS ARC сократился (до 26% ОЗУ), пока не вырос снова.Как все выглядит сейчас?

  • vmstat 5 5 

kthr      memory            page            disk          faults      cpu
r b w   swap  free  re  mf pi po fr de sr vc vc -- --   in   sy   cs us sy id
0 0 0 1372568 2749528 11 41 0  0  0  0  0  2  3  0  0  713  418  539  0  0 99
0 0 0 3836576 4648888 140 228 0 0 0  0  0  0  0  0  0 1178 5344 1117  3  2 95
0 0 0 3840448 4653744 16 45 0  0  0  0  0  0  0  0  0 1070 1013  952  1  3 96
0 0 0 3839168 4652720 6 53  0  0  0  0  0  0  0  0  0  564  575  313  0  6 93
0 0 0 3840208 4653752 7 68  0  0  0  0  0  3  0  0  0 1284 1014 1264  1  1 98
  • swap -s

всего: выделено 4341344 Кбайт + 675384 КЗ зарезервировано = 5016728 КБ использовано, доступно 3840880 КБ

Ответы [ 2 ]

1 голос
/ 29 февраля 2012

Когда в сообщении об ошибке указывается, что пространство подкачки может быть недостаточно большим, я обычно доверяю ему и значительно увеличиваю размер подкачки.

Я бы посоветовал вам сначала сделать это, до 4 ГБ или даже8 гб и посмотрим что получится.Увеличение свопа никак не влияет на производительность.Это распространенное заблуждение.На производительность влияет нехватка оперативной памяти, а не слишком большая область подкачки.

Только если проблема сохраняется после изменения, я пытаюсь исследовать альтернативные треки, например, фрагментацию памяти.

Редактировать:

По выводам memstat, prstat и vmstat ясно, что в вашей системе недостаточно виртуальной памяти.Нет абсолютно никакой необходимости исследовать другие необычные причины, такие как фрагментация памяти.У вас больше свободной оперативной памяти (~ 1,5 ГБ), чем свободной виртуальной памяти (~ 800 МБ).Это означает, что есть много неиспользованных (пока) резервирований памяти.Опять же, просто добавьте пространство подкачки, чтобы это исправить.То есть не будет иметь какое-либо влияние на производительность, так как у вас достаточно ОЗУ.

Редактировать: (часть 2)

Теперь мы знаем, что вы используете ZFS, поскольку ваше приложение может использовать до 8 ГБ (и даже больше, если мы примем во вниманиене кучи памяти), вы должны уменьшить максимальный размер ARC, чтобы обеспечить немедленную доступность этих 8 ГБ для JVM, вместо того, чтобы полагаться на самонастройки, которые выполняет ОС, что в настоящее время может привести к недоразумению при свопинге меньшего размера.Подробнее о том, как это сделать, см. В главе Ограничение ARC-кэша в руководстве по настройке ZFS evil .

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

Вы можете получить эту ошибку, если у вас закончилось пространство main + swap. Хотя объем подкачки 2 ГБ в наши дни довольно мал, если вам приходится использовать пространство подкачки, у вас есть проблема с производительностью, поскольку это означает, что вы заставляете приложения выполнять подкачку на диск.

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

Решение может заключаться в том, чтобы использовать меньше памяти (за счет сокращения других приложений, работающих в системе) или увеличить основную память (16 ГБ для сервера в наши дни не так много, на моем домашнем ПК их 24;)

РЕДАКТИРОВАТЬ: еще одна вещь, которую я видел, причиной этой проблемы является интенсивное использование прямой памяти с кучей памяти. например по умолчанию ваша максимальная прямая память равна максимальному размеру кучи. Это означает, что ваше приложение может использовать почти 8 ГБ прямой памяти перед использованием всей кучи. Приложение может обнаружить, что ОС не хватает основного пространства + подкачки для выделения памяти для кучи и может умереть.

Я стараюсь максимально использовать прямую память, но это сделано для того, чтобы избежать использования большого количества кучи. ;)

...