Ещё по теме

Минимизация воздействия "сборки мусора" в среде Java на производительность системы

Рудольф Майер
2011
3

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

В целом конкурентные условия возникают как следствие разнообразных свойств приложения или системной среды, причем каждая проблема должна решаться отдельно. Однако в приложениях Java типичной причиной таких условий является так называемая “сборка мусора” (GC). Хорошо известно, что процесс сборки мусора воздействует на производительность системы, в частности, на время отклика приложения или пользователя. Вопрос в том, насколько сильно это воздействие? Группа SAP по производительности, управлению данными и масштабируемости столкнулась с этим вопросом на ранней стадии разработки проекта, когда анализ производительности показал немасштабируемое поведение. Также наблюдалась значительная активность процесса сборки мусора. Была ли сборка мусора действительной причиной недостаточной масштабируемости? Или проблема была вызвана конкретными соревновательными условиями приложений? Какой путь следовало избрать для устранения недостатков? Все эти вопросы заставили тщательнее присмотреться к влиянию процесса сборки мусора в среде Java на производительность.

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

Обратите внимание!

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

Вы хотели бы увидеть полную версию статьи?

Если вы являетесь подписчиком журнала SAP Professional Journal, пожалуйста, введите в правом верхнем углу логин и пароль.

Если вы хотите подписаться на журнала SAP Professional Journal, пожалуйста, обратитесь в редакцию или сделайте заказ на сайте.

Правила получения тестового доступа к статьям SAP Professional Journal

Функциональная область: Информационные технологии / IT, Basis, ABAP
Ролевое назначение: Ключевой пользователь / Expert
Комментарии:

Сергей Ляпин (Рейтинг: 140) 10:43, 08 июля 2010

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

Ирина Сергиенко (Рейтинг: 104) 11:20, 26 июля 2010

Спасибо, очень интересно изложен процесс доступа  очистки динамической памяти в среде Java .

Ирина Пащенко (Рейтинг: 30) 13:50, 26 июля 2010

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

Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП» Copyright © 2010 Wellesley Information Services. All rights reserved.