Оптимизация производительности Java в AIX : Часть 2. Увеличение скорости

В этой серии из пяти статей приведены советы и приемы, обычно используемые для настройки Java™-приложений для оптимальной производительности под AIX®. Также даны рекомендации по возможности применения каждого совета. Используя эти советы, можно легко оптимизировать Java-среду под требования приложения.

Амит Матюр, ведущий технический консультант и менеджер по реализации решений, IBM

Амит Матюр (Amit Mathur) работает в группе IBM Solutions Development, занимаясь в основном IBM ISV и возможностями/производительностью приложений на платформе IBM eServer, а также оказывая поддержку пользователям ISV. Пишет статьи и учебные пособия для developerWorks. Амит имеет более чем 14-летний опыт по поддержке разработчиков программного обеспечения и программирования на C/C++, Java, а также баз данных в UNIX и Linux. Он получил степень бакалавра технических наук в области электроники и телекомунникаций в Индии. Связаться с ним можно по адресу amitmat@us.ibm.com.



Сумит Чаула, сертифицированный IT-архитектор IBM и руководитель технической группы, Java Enablement, IBM

Самит Чаула (Sumit Chawla) руководит инициативной группой Java Enablement для IBM eServer (для AIX, Windows и Linux), а также работает консультантом в организации Independent Software Vendors по направлению серверов IBM. Самит имеет степень магистра в области вычислительной техники, обладает более чем 10-летним опытом работы в IT-индустрии, сертифицирован IBM по курсу Application Architect. Он часто пишет статьи для раздела developerWorks eServer. С ним можно связаться по адресу sumitc@us.ibm.com.



25.06.2009

Введение

Это вторая статья в серии из пяти статей о настройке производительности Java на AIX. Перед прочтением этой статьи настоятельно рекомендуется ознакомиться с первой частью, если по каким-то причинам этого не было сделано.

Эта статья рассматривает способы максимально повысить скорость выполнения приложений и пропускную способность системы. Для приложений с интерфейсом пользователя также объясняется, как гарантировать приемлемую скорость отклика системы.

В первом разделе даются общие советы, которые можно применять в различных ситуациях. Также представлены ссылки на инструменты, которые могут использоваться при определении/изучении узких мест, связанных с CPU (центральным процессором). В следующем разделе описаны различные типы приложений и советы по их настройке с учетом специфики приложения. В третьем разделе даются различные советы. Статья заканчивается обзором следующей статьи серии.


CPU как узкое место системы

В этой статье объясняется, как можно повысить скорость работы приложения, в том числе скорость реакции на запросы к нему.

Чтобы определить, работает ли приложение медленно, достаточно сравнить реальные и ожидаемые показатели производительности. Аналогично, интерфейс пользователя в приложении может периодически "зависать" или сетевые подключения могут разрываться по тайм-ауту из-за загруженности приложения. Использование команд topas или tprof покажет, используется ли CPU на 100% или нет. Необходимо отличать нештатные ситуации от ситуаций с недостаточным масштабированием (если требуются более быстрые процессоры или больше процессоров, то эту проблему нельзя решить изменением параметров настройки).

Сначала необходимо с помощью topas или другого аналогичного инструмента посмотреть, является ли Java основным пользователем CPU. Если видно, что Java находится внизу списка пользователей CPU, то детальная настройка процессора вряд ли поможет (краткий обзор topas приведен в первой статье серии).

Идеальный случай, когда приложение использует CPU на 90% или больше. Если достигнуто такое состояние, а пропускная способность остается неудовлетворительной, то причина проблемы - недостаточная мощность системы. Если используется DLPAR, можно попробовать добавить еще один или два CPU и замерить прирост производительности.

В остальной части раздела представлен краткий обзор стандартных инструментов и того, как распознавать проблемы, связанные с Java. Подробная информация приведена в документах AIX 5L Performance Tools Handbook и Understanding IBM eServer pSeries Performance and Sizing.

vmstat

vmstat может использоваться для сбора различной статистки по системе. Для работы с CPU используется следующая команда:

vmstat -t 1 3

В результате сбор статистики будет производиться 3 раза с интервалом в 1 секунду и с указанием временных меток. Параметры можно настроить, как того требует ситуация. Результат работы инструмента показан ниже:

      kthr     memory             page              faults        cpu        time
      ----- ----------- ------------------------ ------------ ----------- --------
       r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa hr mi se
       0  0 45483   221   0   0   0   0    1   0 224  326 362 24  7 69  0 15:10:22
       0  0 45483   220   0   0   0   0    0   0 159   83  53  1  1 98  0 15:10:23
       2  0 45483   220   0   0   0   0    0   0 145  115  46  0  9 90  1 15:10:24

Интересующая нас информация в этом отчете:

  • Значения столбцов r (очередь запуска) и b (блокировано) начинают возрастать, особенно после 10. Это обычно означает, что имеется слишком много процессов, конкурирующих за CPU.
  • Если значение cs (переключения контекста) слишком большое по сравнению с числом процессов, то, возможно, систему надо настроить с помощью vmtune. Данная тема выходит за рамки этой серии статей.
  • В разделе cpu значение us (время пользователя) означает время, использованное программами. Если Java находится вверху списка tprof, тогда необходимо настроить Java-приложение.
  • Если в разделе cpu значение sys (время системы) выше, чем ожидалось и при этом все равно имеется оставшееся id время (время простоя), то это может означать конфликт блокировок. Необходимо проверить через tprof методы, связанные с блокировками, во время работы ядра. Можно попробовать запустить несколько экземпляров JVM. Также можно поискать взаимоблокировки в файле javacore.
  • В разделе cpu, если значение wa (ожидание ввода/вывода) высокое, это может означать, что узким местом является диск, и следует использовать iostat и другие инструменты для изучения использования диска.
  • Ненулевые значения в столбцах pi, po (страницы ввода/вывода) означают, что наблюдается подкачка страниц и необходима дополнительная память. Также может оказаться, что размер стека был установлен слишком большим для некоторых экземпляров JVM. Также это может означать, что была выделена "куча" большего размера, чем количество памяти в системе. Конечно, другие приложения также могут использовать память, или же файлы подкачки занимают слишком много места в памяти.

iostat

Можно использовать iostat, чтобы получить такую же информацию о CPU, как и от vmstat, вместе со статистикой дискового ввода/вывода.

ps

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

ps -ef | grep java

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

 ps -p PID -m -o THREAD

Используя PID (ID процесса) интересующего нас Java-процесса, можно проверить, сколько было создано потоков. Это особенно важно в случае, когда требуется выполнить мониторинг крупного приложения, так как можно перенаправить вывод этой команды в команду wc -l для получения числа потоков, созданных JVM. Это может выполняться циклически, так что можно определить, какие потоки запускаются или умирают в неположенное время.

ps au[x]

Полезно получить значения %CPU%Memory, отсортированные по самым активным пользователям. Это полезно для быстрого поиска узких мест в системе.

ps v[g]

Показывает использование виртуальной памяти. Стоит отметить, что предпочтительнее выполнять мониторинг платформенно-зависимой и Java-"кучи" через svmon. Подробнее это объясняется в третьей статье этой серии.

 ps eww PID

Используя PID (ID процесса), можно получить информацию о настройках среды процесса. Например, показать полный файловый путь выполняемого Java-приложения, который может не показываться в обычном выводе команды ps. Отметим, что для того чтобы получить полную информацию о среде, рекомендуется создать файл javadump (дамп Java) (см. статью IBM developer kits - diagnosis documentation).

sar

sar -u -P ALL x y можно использовать для проверки баланса использования CPU при использовании нескольких центральных процессоров. Если распределение не сбалансировано, это может означать, что приложение однопоточное и, возможно, требуется запустить несколько экземпляров приложения. В примере, приведенном ниже, выполняется сбор статистики 2 раза с интервалом в 5 секунд на двухпроцессорной системе, которая используется на 80%.

        # sar -u -P ALL 5 2

        AIX aix4prt 0 5 000544144C00    02/09/01

        15:29:32 cpu    %usr    %sys    %wio   %idle
        15:29:37  0       34      46       0      20
                  1       32      47       0      21
                  -       33      47       0      20
        15:29:42  0       31      48       0      21
                  1       35      42       0      22
                  -       33      45       0      22

        Average   0       32      47       0      20
                  1       34      45       0      22
                  -       33      46       0      21

Можно видеть, что все CPU используются на 100% (когда выполняются продолжительные benchmark-циклы), или только один CPU используется на 100% (когда JVM выполняет сжатие памяти). Это значит, что необходимо выполнить настройку с помощью verbosegc; см. статью Fine-tuning Java garbage collection performance.

tprof

tprof - это один из традиционных инструментов AIX, предоставляющий детальную информацию по профилю использования CPU для каждого AIX-процесса по имени или идентификатору. Он был полностью переписан в AIX 5.2, а в примере, приведенном ниже, используется синтаксис AIX 5.1 syntax. С новым синтаксисом можно ознакомиться в статье AIX 5.2 Performance Tools update: Part 3.

Самый простой способ вызвать эту команду:

 # tprof -kse -x "sleep 10"

Через 10 секунд будет создан новый файл __prof.all, содержащий информацию о том, какие команды используют CPU-системы. Если отсортировать данные по FREQ (частота), то информацию можно представить следующим образом:

              Process   FREQ  Total Kernel   User Shared  Other
              =======    ===  ===== ======   ==== ======  =====
               oracle    244  10635   3515   6897    223      0
                 java    247   3970    617      0   2062   1291
                 wait     16   1515   1515      0      0      0
    ...
              =======    ===  ===== ======   ==== ======  =====
                Total   1060  19577   7947   7252   3087   1291

Этот пример показывает, что половина времени CPU связана с приложением Oracle, и Java использует около 3970/19577 или 1/5 ресурсов CPU. Значение в ряду wait обычно означает время простоя, но может также включать долю использования CPU, затраченного на ожидание ввода/вывода.

Чтобы увидеть, есть ли в системе конфликт блокировок, необходимо проверить раздел KERNEL (ядро):

       Total Ticks For All Processes (KERNEL) = 7787

     Subroutine                Ticks  %   Source   Address Bytes
     =============             ===== ==== ======== ======== ======
     .unlock_enable_mem         2286 11.7 low.s    930c     1f4
     .waitproc_find_run_queue   
     1372  7.0 ../../../../../src/bos/kernel/proc/dispatc h.c 2a6ec    2b0
     .e_block_thread             893  4.6 ../../../../../src/bos/kernel/proc/sleep2.

В разделе Shared Objects (общие объекты) необходимо обратить внимание на записи с libjvm.a и особенно на записи с именем gc_* или именами, похожими на названия этапов деятельности (Mark, Sweep, Compact). Если таких записей много, то, возможно, необходимо выполнить настройку GC (сборщика мусора) для процесса JVM.

Также нужно обращать внимание на важные процедуры, которые потребляют большое число тактов (Ticks) процессора. Например, один из отчетов tprof показывает, что значение для метода clProgramCounter2Method достаточно высокое:

    Subroutine                Ticks  %   Source   Address Bytes
     =============             ===== ==== ======== ======== ======
     .clProgramCounter2Method   3551 14.8 /userlvl/ca131/src/jvm/sov/cl/clloadercache.c

После исследования нескольких таких примеров было установлено, что удаление вызовов метода Throwable.printStackTrace значительно улучшает производительность. Расследование, которое привело к этому методу, было начато с анализа информации, полученной от tprof.

Советы, относящиеся к Java

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

Garbage Collection (сборщик мусора) - это еще один жизненно важный для производительности компонент, так что он должен быть исследован и настроен при необходимости. Отметим, что хотя включение трассировки GC (с помощью параметра -verbosegc) оказывает небольшое негативное влияние, преимущество возможности мониторинга и анализа Java-"кучи" превышает отрицательный эффект. Если взглянуть с другой стороны, то правильно функционирующая, здоровая "куча" минимизирует количество информации, выводимой через -verbosegc, так что с настройкой "кучи" можно заодно минимизировать затраты на дополнительную трассировку.


Советы по настройке, основанные на специфике приложения

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

Длительность работы приложения

Реализация Java от IBM спроектирована так, чтобы обеспечить лучшие характеристики для приложений, рассчитанных на работу в течение длительного времени, например, серверного кода. Если по какой-то причине запускается сценарий тестирования, длящийся 5 минут или меньше, то можно обнаружить, что приготовления, выполняемые Java от IBM для подготовки к длительной работе, влияют на время запуска. Стоит посмотреть на советы CPU001: быстрый запуск приложения и CPU004: полное освобождение от GC, если быстрый запуск для приложения важнее, чем длительная работа. Если совет CPU004: полное освобождение от GC не помогает, вместо него можно попробовать использовать совет CPU012: как избежать изменения размеров "кучи". В сложных случаях можно попробовать выполнить тестирование с отключенным JIT, если сценарий тестирования настолько короткий, что даже инициализация JIT оказывается затратной. Стоит отметить, что отключение JIT до сих пор не упоминалось в качестве самостоятельного совета по настройке производительности, так как в предыдущей статье говорилось, что это, возможно, самая худшая вещь для производительности приложения.

Если приложение может позволить себе небольшую задержку во время запуска, стоит изучить советы CPU003: скомпилировать все при первой возможности и CPU008: использование небольшой "кучи". Для долго работающих приложений, которые имеют четко выделенные фазы "инициализация" и "работа", совет CPU003: скомпилировать все при первой возможности очень полезен.

Уровень взаимодействия с пользователем

В зависимости от того, насколько интенсивны вычисления, выполняемые в коде, скорость отклика JVM может колебаться от критической до несущественной. Если настраиваемая JVM исполняет GUI-приложение, то длинные паузы, вызываемые GC, будут неприемлемыми. В то же время, если работают несколько экземпляров JVM, которые позволяют балансировать нагрузку, или выполняется обработка данных в пакетном режиме, то долгие паузы вполне допустимы.

Для приложений, у которых недопустимы длинные паузы в работе, подходят советы CPU002: использование параллельного GC, CPU004: полное освобождение от GC, CPU007: отключение явных вызовов метода System.gc(), CPU008: использование небольшой "кучи ", CPU009: устранение переполнения стека и CPU012: как избежать изменения размеров "кучи". Совет CPU004 в большинстве ситуаций можно применять только для недолго работающих приложений. Отметим, что совет CPU008 должен рассматриваться вместе с характеристиками приложения, связанными с памятью, иначе он может привести к обратному эффекту, если будет применен неправильно.

Для приложений, у которых допустимы длинные паузы в работе, можно применить совет CPU003: скомпилировать все при первой возможности. Стоит отметить, что наличие длинных пауз в работе - это плохой признак в большинстве случаев, так что стоит изучить и устранить проблему, потому что невозможно получить никаких преимуществ от ненастроенного экземпляра JVM.

Потребление ресурсов CPU

Если приложение запускается с числом потоков большим, чем число установленных CPU, и при этом считается нормальной ситуация, когда общее использование CPU находится на уровне 90% или выше, то любая фоновая обработка данных ухудшит пропускную способность приложения. С другой стороны, если приложение - это сервер, потоки которого "спят" большую часть времени и "просыпаются" только для обработки входящих запросов, то можно уменьшить эффект от длительных пауз на работу GC с помощью фоновой обработки.

Для приложений, которые интенсивно используют CPU и поэтому требуют минимизации фоновой обработки данных, стоит рассмотреть советы: CPU007 : отключение явных вызовов метода System.gc(), CPU008 : использование небольшой "кучи", CPU009 : устранение переполнения стека. Совет CPU008: использование небольшой "кучи" необходимо рассматривать одновременно с характеристиками памяти, как упоминалось ранее.

Для приложений, неинтенсивно использующих CPU, крайне рекомендуется совет CPU002: использование параллельного GC. Это позволит получить преимущества, снизив общее время пауз в приложении, когда выполняется рабочий цикл GC.

Правильно определенное местонахождение ссылок

Если в приложении имеются несколько методов, которые выполняются очень часто, а другие методы исполняются редко, то совет CPU003: скомпилировать все при первой возможности может оказаться очень полезным для улучшения производительности.

Степень параллелизма

Если приложение запускает несколько потоков для выполнения работы, то оно получит преимущество от системы, в которой имеется большое число CPU. Для динамических разделов (dynamic partition) добавление дополнительных CPU сразу же даст положительный эффект, так как Java-потоки могут быть немедленно запланированы на исполнение на вновь добавленных CPU. В советах CPU005: большое число потоков, CPU006: уменьшение конфликтов блокировок и CPU011: системы с более чем 24 CPU обсуждаются другие варианты оптимизации, которые можно попробовать.

Но если приложение имеет только один поток исполнения, то оно будет ограничено вычислительной мощностью единственного CPU. В этом случае можно попробовать использовать советы CPU002: использование параллельного GC и CPU010: системы с единственным CPU. Совет CPU010: системы с единственным CPU особенно полезен, если требуется запустить несколько экземпляров JVM в системе (например, в кластерной среде).


Стандартный набор советов

В тексте, приведенном ниже, имеются ссылки на аргументы командной строки для Java, указываемые перед именем класса/jar-файла и известные как "переключатели" (switches). Например, в строке java -mx2g hello есть единственный переключатель -mx2g.

Совет CPU001: быстрый запуск приложения

Нестандартный переключатель -Xquickstart может использоваться для сокращения времени запуска приложения. Этот переключатель снижает уровень JIT-оптимизаций до минимума и применяет их снова, только если подходящие методы снова становятся активно используемыми. В результате приложения, где логика исполнения не концентрируется в небольшом числе методов, запускаются намного быстрее.

Примечание: стоит отметить, что с точки зрения многоэтапного подхода к оптимизации этот переключатель может оказать неблагоприятное влияние на длительно работающие приложения.

Совет CPU002: Использование параллельного GC

Можно указать параллельную политику для сбора мусора (Concurrent Mark Garbage Collection Policy) для того, чтобы снизить число пауз, возникающих из-за рабочих циклов GC. Эта политика определяется с использованием переключателя -Xgcpolicy:optavgpause.

Примечание: в некоторых случаях приложения, интенсивно использующие ресурсы CPU, могут показать снижение пропускной способности при использовании параллельного режима.

Совет CPU003: скомпилировать все (или выбранные методы) при первой возможности

Переменная окружения IBM_MIXED_MODE_THRESHOLD может быть установлена в 0 для того чтобы отключить интерпретатор смешанного режима (mixed-mode interpreter). Это приведет к тому, что все методы будут откомпилированы JIT после того как их вызовут в первый раз. Необходимо добавить эту строку в настройки окружения или просто запустить ее перед запуском Java:

export IBM_MIXED_MODE_THRESHOLD=0

Также можно поэкспериментировать с ненулевыми значениями чтобы увидеть, какой конкретно порог MMI дает производительность лучше, чем у нулевого значения. Для AIX Java 1.3.1 использует 600 в качестве порогового значения, тогда как Java 1.4 использует значение больше 1000 (отметим, что эти значения имеют обыкновение меняться со временем). В статье IBM developer kits - diagnosis documentation , в главе "JIT Diagnostics", есть раздел "Selecting the MMI Threshold", в котором предоставляется дополнительная информация.

Если имеются только определенные классы, на которые необходимо воздействовать, то можно вместо этого использовать JITC_COMPILEOPT=FORCE(0){classname}{methodname}. Пример:

export JITC_COMPILEOPT=FORCE(0){com/myapp/*}{*}

Этот пример компилирует все методы в пакете com.myapp.* при первой загрузке.

export JITC_COMPILEOPT=FORCE(0){*}{uniqueName}

Этот пример компилирует все методы, называемые "uniqueName", при их первой загрузке.

export JITC_COMPILEOPT=FORCE(0){com/myapp/special}{SpecialMethod}

Этот пример компилирует только этот конкретный метод при первой загрузке. Вместе с шаблоном * (используется как "0 или более символов") можно использовать шаблон ? для отдельных символов.

Множество классов и/или методов может быть определено с помощью следующего синтаксиса:

export JITC_COMPILEOPT=FORCE(0){class1}{method1}{class2}{method2}

Важно четко отразить в документации, что это оптимизация, а не исправление ошибки!

Примечание: время запуска приложений может возрасти из-за этой настройки.

Совет CPU004: полное отключение GC

Стартовый и максимальный размеры "кучи" могут быть установлены в такие большие значения, что за время работы не произойдет ошибок во время выделения памяти. Обязательно необходимо включить verbosegc при подобном режиме работы, чтобы убедиться, что эта стратегия действительно работает!

Примечание: Когда происходит срабатывание GC, цикл его работы, скорее всего, займет много времени, так что этот совет можно использовать в очень редких случаях.

Совет CPU005: большое число потоков

Для масштабирования на большое число потоков стоит использовать переключатель -Xss для определения значения меньшего, чем по умолчанию (обычно 512 КБ, но может меняться в зависимости от версии Java). Это позволит выполнить масштабирование на большее число потоков, одновременно снизив количество платформенно-зависимой памяти, используемой приложением.

Примечание: Если размер стека слишком мал, может возникнуть исключительная ситуация Stack Overflow (переполнение стека).

Совет CPU006: уменьшение числа конфликтных блокировок

Можно попробовать запустить несколько экземпляров Java, если архитектура приложения позволяет это, чтобы уменьшить число конфликтных блокировок. Это поддерживается серверами приложений, позволяющими такой тип конфигурации, например, WebSphere позволяет использовать несколько экземпляров на одном компьютере.

Примечание: стоит отметить, что это может только скрыть проблему, так что стоит еще раз изучить фрагменты кода, которые приводят к чрезмерному числу конфликтных блокировок. Можно использовать tprof или средство профилирования для Java для поиска областей, которые следует изучить еще раз.

Совет CPU007: Отключение явных вызовов метода System.gc()

Используя нестандартный переключатель -Xdisableexplicitgc, можно избавиться от необходимости удалять вызовы метода System.gc() из кода. Удаление этих вызовов вернет управление GC обратно к JVM.

Примечание: Если вызов System.gc() необходим для функциональности, например, для кнопки на экране приложения, то это будет плохая идея, так как кнопка перестанет функционировать. Могут также быть другие обоснованные причины для присутствия вызовов System.gc() в коде.

Совет CPU008: использование "кучи" небольшого размера

Можно использовать "кучу" такого размера, что она никогда не потребует недопустимо много времени для уплотнения информации. Если по какой-то причине, приложение прекращает работу из-за необходимости длительного сжатия информации, то "куча" в 256 MБ потребует куда меньше времени для сжатия, чем "куча" в 1 ГБ.

Примечание: Если в результате уменьшения размера "кучи" потребуется больше сжатий, то оптимизация сработает в противоположную сторону. Этот совет можно использовать только в ситуациях, когда создается много временных объектов.

Совет CPU009: устранение переполнения стека

Если в журналах verbosegc присутствуют сообщения Mark Stack Overflow (зафиксировано переполнение стека), стоит уменьшить число объектов, хранящихся в "куче", чтобы эти сообщения исчезли. Новые сборки Java обладают улучшенной обработкой ситуаций с MSO. Эта возможность была добавлена, так как проблема MSO может серьезно повредить производительности приложения и должна рассматриваться как дефект, а не оптимизация.

Совет CPU010: системы с единственным CPU

Можно использовать команду bindprocessor, чтобы привязать Java-процесс к определенному процессору. Этот вариант можно рассмотреть, чтобы избежать ситуации, когда несколько экземпляров JVM конкурируют за ресурсы CPU. Также можно установить переключатель -Xgcthreads0 если система не однопроцессорная.

Если приложение работает на 1-CPU LPAR, который нельзя переконфигурировать, чтобы динамически добавить еще несколько CPU, можно также экспортировать переменную окружения NO_LPAR_RECONFIGURATION=1 для получения лучшей производительности в определенных случаях.

Примечание: Лучшие возможности Java для производительности отключаются, когда ее заставляют работать в однопроцессорной конфигурации. Переменная окружения NO_LPAR_RECONFIGURATION также отключит динамическую конфигурируемость Java для адаптации к DLPAR, так что ее следует использовать с осторожностью.

Совет CPU011: системы более чем с 24 CPU

Для систем, у которых от 24 до 32 процессоров, стоит протестировать переключатель -Xgcpolicy:subpool, так как эта политика GC настроена для обеспечения лучшей производительности для крупных конфигураций.

Совет CPU012: отключение изменения размеров "кучи"

Можно поддерживать "кучу" фиксированного размера чтобы избежать траты времени на изменение размера "кучи", когда процент свободного пространства уменьшается или вырастает выше определенного значения. Подробная информация приведена в статье Fine-tuning Java garbage collection performance.

Примечание: Количество памяти, используемой приложением, будет соответствовать размеру, установленному для "кучи", даже если "куча" используется на 10% от максимального уровня.


Заключение

Эта статья рассказывает, как использовать инструменты AIX для мониторинга производительности Java и содержит советы, которые можно применять для оптимизации использования CPU приложением. В следующей статье серии будут разбираться приемы для настройки памяти для Java-приложений в ОС AIX.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=AIX и UNIX
ArticleID=399434
ArticleTitle=Оптимизация производительности Java в AIX : Часть 2. Увеличение скорости
publish-date=06252009