влияние менеджеров виртуальной памяти на производительность J2EE приложений
Мы изучаем влияние менеджеров виртуальной памятии (VMM, Virtual Memory Manager) операционных систем на производительность корпоративного программного обеспечения. Для исследований мы выбрали несколько популярных семейств ядра Linux и внесли изменения в настройки их VMM. Производительность измерялась в тесте ECPerf J2EE. Для запуска теста мы использовали сервер приложений JBoss. Результаты наших тестов показывают, что изменение даже одного параметра в VMM может оказать значительное влияние на производительность. В работе представлены степень влияния параметров и определенных установок. Также было проведено сравнение производительности ядер различных разных семейств между собой.
введение
На сегодняшний день модульные системы работают как на уровне программного обеспечения, так и на уровне железа. Типичная J2EE-система запускается внутри сервера приложений, который, в свою очередь, запускается внутри виртуальной Java-машины, которая запускается в операционной системе. Сами же операционные системы запускаются либо непосредственно на железе, либо работают в под управление другой ОС. Не смотря на большое преимущество подобной многоуровневой системы, она приводит к определенным сложностям: например, результаты изменений на более низких уровнях не всегда очевидны, особенно, если уровни не взаимодействуют напрямую. Сложно предвидеть изменения в производительности J2EE-приложения, если какой-либо определенный параметр в ОС был изменен.
Мы исследуем результаты изменений параметров VMM и влияние этих изменений на производительность J2EE-приложений. Были рассмотрены и протестированы ядра Linux различных семейств. Как мы и предполагали, изменение параметров VMM отразилось на производительности, что и было зафиксировано как в тесте ECPerf, так и в стандартном тесте производительности J2EE. При этом были выявлены параметры, которые ухудшали производительность больше других. В результате был проведен анализ степени влияния определенных параметров VMM на производительность. Мы не пытались понять причину различий производительности, так как для этого требуется проанализировать исходные коды VMM и все остальные отличия ядер. Мотивация иследования не в поиске причин различий производительности, а в том, чтобы доказать, что различия есть и игнорировать их нельзя.
семейства ядер и параметры VMM
Процесс разработки ядра Linux не является централизованным или объединенным процессом – каждый волен разветвлять код и поддерживать свой собственный репозиторий. То есть, несмотря на то, что основная разработка ведется в официальной версии vanilla, релизы которой доступны с основного репозитория, многие поставщики Linux и разработчики ядра поддерживают и развивают свои собственные ответвления, которые содержат определенные изменения и увеличенную функциональность. Причины подобного поведения распространителей следующие: неограниченная возможность добавления поддержки нового оборудования, улучшение безопасности, увеличение стабильности и производительности, поддержка совместимости со старшими версиями и быстрое исправление ошибок. Некоторые семейства ядер служат в качестве тестовых площадок для новых эксперементальных возможностей, которые в последствии, когда станут стабильными и полезными, присоединятся к основной ветви ядра.
Было протестировано несколько семейств Линукс. Основным критерием выбора стало наличие последних изменений в VMM. Итак, выбраны были следующие семейства:
- Debian 2.4;
- Debian 2.6;
- SUSE;
- Fedora Core;
- Alan Cox (-ac);
- Andrew Morton (-mm);
- Con Kolivas (-ck).
Debian 2.4 был выбран, чтобы сравнить производительность между семействами ядер 2.4.* и 2.6.*. Также было решено использовать две версии ядер для SUSE – одно с конфигурацией по умолчанию, второе – с конфигурацией, которая поставляется со всеми другими образами ядер. Все ядра, кроме Debian'овских 2.4.26 и 2.6.8, были откомпилированы нами локально компилятором gcc-3.3.5.
параметры VMM
Рассматриваться будет VMM текущей стабильной ветки Линукса – 2.6. Были проанализированы параметры VMM, которые обычно можно изменять во время выполнения программы через интерфейс /proc/sys/vm. Был создан список параметров, которые теоретически могут повлиять на производительность. Основываясь на описаниях параметров, мы разделили их на две группы – красная и синяя. Во время экспериментов мы исследуем предположение о том, что красная группа сильнее влияет на производительность VMM, чем синяя.
Красная группа:
- dirty_background_ratio – процент памяти, который разрешен для хранения данных кэширования или не сохраненных данных;
- dirty_expire_centisecs – наибольшее количество сотых долей секунд, во время которых данным разрешено оставаться в кэше;
- dirty_ratio – показывает, сколько можно использовать памяти для хранения данных, не синхронизированных с диском; указывается в процентах от всей оперативной памяти;
- dirty_writeback_centisecs – интервал между периодическими просыпаниями демона pdflush, отвечающего за запись «грязных» буферов на диск; - page-cluster – число, представляющее, сколько страниц может быть записано в файл подкачки за одну попытку;
- swappiness – определяет интенсивность использования файла подкачки.
Синяя группа:
- lower_zone_protection – резервирует нижнюю память для блокируемого выделения за счет уменьшения объема памяти, доступной для страничного кэша; - min_free_kbytes – говорит виртуальной машине резервировать указанный объем памяти;
- vfs_cache_pressure – контролирует стремление ядра восстановить память, которая использована для кэширования директорий и объектов типа «индексный узел»;
- overcommit_memory – управляет возможностью выделения памяти большего объема, чем реально существует.
используемое железо
В тестировании были задействованы три x86 машины:
- сервер приложений: Pentium III-866 МГц, 512 Мб;
- сервер баз данных: Pentium III-800 МГц, 512 Мб;
- клиент: Pentium IV-2.2 МГц, 1 Гб.
Чтобы быть уверенными, что не возникнет «пробок» во время создания тестовой загрузки, клиентскую машину сделали самой мощной (она должна быть как минимум такая же по мощности, как и серверы).
используемое программное обеспечение
Мы использовали следующее программное обеспечение:
- операционная система: Debian GNU/Linux 3.1 'sarge';
- база данных: MySQL v. 5.0.7beta-1;
- сервер приложений: JBoss v.4.01sp1 (Java2 SDK 1.4.2_08);
- клиент: ECPerf suit 1.1 (Java2 SDK 1.4.2_08).
На всех машинах был использован Debian 'sarge'. Доступная память для Java была выставлена в 384Mb.
ECPerf и его настройка
ECPerf – это средство тестирования Enterprise JavaBeans (EJB), которое используется, чтобы определить возможность масштабирования и производительности серверов и контейнеров J2EE. Этот тест сильно нагружает возможности EJB-контейнеров по манипулированию управлением памятью, организацией связного пула, пассивацией/активацией и кэшированием. ECPerf первоначально разрабатывался в Sun Microsystems, но на данный момент разрабатывается и поддерживается корпорацией SPEC, которая распространяет данный продукт под названием SPEC-jAppServer2004.
Конфигурация ECPerf: во время подготовки эксперимента была определена следующая нагрузка как приносящая наилучшую производительность: txRate = 5, runOrderEntry = 1, runM fg = 1. Нагрузка эквивалентна 40 потокам: 25 потоков для упорядоченного поступления и 15 потоков для запланированных действий.
Установки режимов:
- запуск: rampUp = 480, 8 минут;
- устойчивый: stdyState = 600, 10 минут;
- выключение: rampDown = 180, 3 минуты.
алгоритм тестирования
Приведенный ниже псевдокод описывает алгоритм тестирования, используемый при исследованиях. Приведем краткое описание.
Каждая из система установлена и запущена; затем для каждого параметра в красном или в синем списках мы устанавливаем определенное значение. Далее идет очистка памяти и базы данных, отключение своппинга и перезапуск сервера приложений. Результаты сохраняются для каждого отдельного запуска для дальнейшего анализирования.
for(система установлена) {
запуск системы;
for(меняем параметр) {
меняем значение параметра;
new average; //среднее время
for(int i = 0; i++; i < 3) {
очищаем память;
очищаем базу данных;
отключаем своппинг;
average += avg(run_ecperf());//заносим результат
}
save_tuple(kernel, parameter, value, average);//сохраняем результаты
}
}
Значения параметров VMM изменялись два, три или четыре раза в зависимости от типа параметра. Также были проведены тесты с установками по умолчанию. Разделы свопинга были отключены на время проведения тестирования, что должно было привести к увеличению производительности.
результаты и анализ
На рисунке 1 показаны все результаты, полученные во время измерений. Они показывают среднюю производительность по ECPerf, которая представленна в количестве операций за минуту в бизнес приложениях. Наибольшие и наименьшие значения производительности брались по три раза, в то время как тестирование при установках по умолчанию проводилось по 10 раз. Среднее увеличение производительности по сравнению со стандартными установками составило 5,19%, а среднее падение производительности в результате непреднамеренного изменения конфигурации составило -8,73%. Падение производительности не относится к параметру min_free_kbytes, который, если установлен слишком большим, останавливает работу ОС.
Рис. 1. Общие результаты.
Надо отметить, что ядра Debian, на наш взгляд, более чувствительны к изменениям в конфигурации. Семейство ядер SUSE показало схожую производительность в двух конфигурациях: в измененной и в конфигурации, идущей вместе с SUSE. Также семейство ядер, поддерживаемое Коном Коливасом (Con Kolivas) продемонстрировало схожее падение производительности на всех уровнях – цена, которую приходится платить за улучшение пользовательской интерактивности и за переключение контента. Референсный тест (семейство ядер 2.4) продемонстрировал значительно более медленные результаты, чем его эквивалент на семействе ядра 2.6. Семейство ядер Эндрю Мортон (Andrew Morton), которое является экспериментальной площадкой для новых фич, продемонстрировало увеличение производительности относительно серий 2.6.11, что в последствии нашло свое отражении в основной линейке 2.6.14, а затем с доработкой и в 2.6.15. Данные три ядра на наш взгляд ведут себя лучше в базовой конфигурации.
Мы утверждаем, что 5%-ное увеличение производительности - достаточно важный результат, считая тот факт, что это вызвано изменением только одного значения в параметрах VMM. В нижестоящей таблице представлены результаты для каждого ядра.
Таблица 1. Максимумы и минимумы производительности для различных ядер, %.
обработка результатов
На рисунке 2 для каждого ядра показаны число непройденных тестов и среднее отклонение от результатов. Они довольно невелики, поскольку общее количество тестов включает: 11 параметров ядра * 3 значения * 3 ECPerf-теста = 99. Причиной провала большинства непройденных тестов была установка параметра «min_free_kbytes» равным 256 Мб, который забирал часть памяти у сервера приложений. Поскольку вдруг часть памяти становилась недоступной, JVM не могла запуститься, таким образом провалив тест. Предположение о предварительном разделении параметров VMM на красные и синие группы оказалось частично верным, хотя наихудшие показания продемонстрировало изменение параметра min_free_kbytes.
Самая верхняя линия на рисунке 2 показывает среднее эталонное отклонение для тестов. Можно отметить, что ядра Debian имеют большее отклонение, в то время как худшее у ядра Con Kolivas'a.
Рис. 2. Число непройденных тестов и среднее отклонение результатов.
Результаты общего анализа чувствительности представлены на рисунке 3. Они показывают параметры ядра, которые имеют наисильнейшее, но не обзательное лучшее влияние на производительность J2EE-системы. Эта круговая диаграмма была получена следующим образом: суммировалась разница производительности каждого ядра при определенных настройках, так было проделано для каждого параметра, затем по этим данным была построена диаграмма. Вот формула:
sensivity = ?(stdev(параметр, ядро)) (1)
Видно, что dirty_expire_centisecs и min_free_kbytes имеют наибольшее влияние на производительность. Изменение остальных параметров воздействует на производительность в меньшей степени. Более детально это показано на рисунке 4.
Попытка определить, какая из настроек VMM реально дает более лучшую производительность, отображена на рисунке 5. Задача нетривиальна, поскольку не было явного лидера – каждое ядро имело свои «выигрышные» настройки. Чтобы обойти это затруднение, результаты для каждого ядра были отсортированы по производительности при работе с бизнес-приложениями и каждому из 33 параметров было сопоставлено значение от одного (худшая производительность) до 33(для демонстрации лучшей производительности). Затем соответствующие параметры и их значения были сгруппированы по семействам ядер.
Рис. 3. Общая чувствительность разнообразных настроек VMM.
Рис. 4. Чувствительность различных настроек VMM и ядер.
Рис. 5. Степень воздействия параметров на производительность.
Результаты были разделены на три категории: «возможно позитивные», «неопределенные», «негативные». Установки в группе «возможно позитивные» больше похожи на настройки, которые могут увеличить производительность, а настройки группы «негативные» значительно ухудшают производительность. Оставшиеся настройки были протестированы, чтобы определить, какие из них и для каких задач дают большую производительность.
проделанная работа
Исследование зависимости производительности J2EE в основном имеет дело с уровнем программного обеспечения, который лежит ниже самих приложений, то есть с сервером приложений. Две наиболее известные работы:
- Gorton, I., Liu, A., Brebner, P.: Rigorous Evaluation of COTS Middleware (Technology IEEE Computer Mar (2003) 50-55);
- Cecchet, E., Marguerite, J., Zwaenepoel, W.: Performance and Scalability of EJB Applications (Proc. of 17th ACM Conference on Object- Oriented).
Сейчас много предпринимается для исследования JVM, хотя основные темы - общая оптимизация работы и сборка мусора. Также более ранние исследования авторов касались воздействия методов ввода параметров на производительность EJB-приложений.
выводы и будущая работа
Используя ECPerf-тест, мы протестировали многие семейства ядер Линукса, чтобы определить, влияют ли изменения настроек VMM на производительность J2EE-приложений. Параметры, которые влияют на производительность, подверглись анализу.
Мы аргументировали, что производительность изменилась более чем на 5% при изменении всего лишь одного параметра VMM. Это важно, и на это нельзя закрывать глаза, особенно имея дело с системами, чувствительными к производительности.
Есть планы для более детального исследования, которое будет включать различные параметры оптимизации и большее количество серверных приложений: WebSphere Community Edition, WebSphere Enterprise Edition. Мы также планируем оценить влияние различных процессов и планировщиков ввода-вывода на производительность J2EE.
Александр Уфимцев, alexu@ucd.ie, Елена Кучеренко, alena_kucharenka@tut.by, Лиам Мерфи, Liam.Murphy@ucd.ie, Лаборатория исследования производительности, Школа вычислительной техники и информатики, Колледж при университете Дублина.Перевод Дмитрия Канаева.Авторы с благодарностью приняли помощь от «Informatics Research Initiative of Enterprice Ireland».
введение
На сегодняшний день модульные системы работают как на уровне программного обеспечения, так и на уровне железа. Типичная J2EE-система запускается внутри сервера приложений, который, в свою очередь, запускается внутри виртуальной Java-машины, которая запускается в операционной системе. Сами же операционные системы запускаются либо непосредственно на железе, либо работают в под управление другой ОС. Не смотря на большое преимущество подобной многоуровневой системы, она приводит к определенным сложностям: например, результаты изменений на более низких уровнях не всегда очевидны, особенно, если уровни не взаимодействуют напрямую. Сложно предвидеть изменения в производительности J2EE-приложения, если какой-либо определенный параметр в ОС был изменен.
Мы исследуем результаты изменений параметров VMM и влияние этих изменений на производительность J2EE-приложений. Были рассмотрены и протестированы ядра Linux различных семейств. Как мы и предполагали, изменение параметров VMM отразилось на производительности, что и было зафиксировано как в тесте ECPerf, так и в стандартном тесте производительности J2EE. При этом были выявлены параметры, которые ухудшали производительность больше других. В результате был проведен анализ степени влияния определенных параметров VMM на производительность. Мы не пытались понять причину различий производительности, так как для этого требуется проанализировать исходные коды VMM и все остальные отличия ядер. Мотивация иследования не в поиске причин различий производительности, а в том, чтобы доказать, что различия есть и игнорировать их нельзя.
семейства ядер и параметры VMM
Процесс разработки ядра Linux не является централизованным или объединенным процессом – каждый волен разветвлять код и поддерживать свой собственный репозиторий. То есть, несмотря на то, что основная разработка ведется в официальной версии vanilla, релизы которой доступны с основного репозитория, многие поставщики Linux и разработчики ядра поддерживают и развивают свои собственные ответвления, которые содержат определенные изменения и увеличенную функциональность. Причины подобного поведения распространителей следующие: неограниченная возможность добавления поддержки нового оборудования, улучшение безопасности, увеличение стабильности и производительности, поддержка совместимости со старшими версиями и быстрое исправление ошибок. Некоторые семейства ядер служат в качестве тестовых площадок для новых эксперементальных возможностей, которые в последствии, когда станут стабильными и полезными, присоединятся к основной ветви ядра.
Было протестировано несколько семейств Линукс. Основным критерием выбора стало наличие последних изменений в VMM. Итак, выбраны были следующие семейства:
- Debian 2.4;
- Debian 2.6;
- SUSE;
- Fedora Core;
- Alan Cox (-ac);
- Andrew Morton (-mm);
- Con Kolivas (-ck).
Debian 2.4 был выбран, чтобы сравнить производительность между семействами ядер 2.4.* и 2.6.*. Также было решено использовать две версии ядер для SUSE – одно с конфигурацией по умолчанию, второе – с конфигурацией, которая поставляется со всеми другими образами ядер. Все ядра, кроме Debian'овских 2.4.26 и 2.6.8, были откомпилированы нами локально компилятором gcc-3.3.5.
параметры VMM
Рассматриваться будет VMM текущей стабильной ветки Линукса – 2.6. Были проанализированы параметры VMM, которые обычно можно изменять во время выполнения программы через интерфейс /proc/sys/vm. Был создан список параметров, которые теоретически могут повлиять на производительность. Основываясь на описаниях параметров, мы разделили их на две группы – красная и синяя. Во время экспериментов мы исследуем предположение о том, что красная группа сильнее влияет на производительность VMM, чем синяя.
Красная группа:
- dirty_background_ratio – процент памяти, который разрешен для хранения данных кэширования или не сохраненных данных;
- dirty_expire_centisecs – наибольшее количество сотых долей секунд, во время которых данным разрешено оставаться в кэше;
- dirty_ratio – показывает, сколько можно использовать памяти для хранения данных, не синхронизированных с диском; указывается в процентах от всей оперативной памяти;
- dirty_writeback_centisecs – интервал между периодическими просыпаниями демона pdflush, отвечающего за запись «грязных» буферов на диск; - page-cluster – число, представляющее, сколько страниц может быть записано в файл подкачки за одну попытку;
- swappiness – определяет интенсивность использования файла подкачки.
Синяя группа:
- lower_zone_protection – резервирует нижнюю память для блокируемого выделения за счет уменьшения объема памяти, доступной для страничного кэша; - min_free_kbytes – говорит виртуальной машине резервировать указанный объем памяти;
- vfs_cache_pressure – контролирует стремление ядра восстановить память, которая использована для кэширования директорий и объектов типа «индексный узел»;
- overcommit_memory – управляет возможностью выделения памяти большего объема, чем реально существует.
используемое железо
В тестировании были задействованы три x86 машины:
- сервер приложений: Pentium III-866 МГц, 512 Мб;
- сервер баз данных: Pentium III-800 МГц, 512 Мб;
- клиент: Pentium IV-2.2 МГц, 1 Гб.
Чтобы быть уверенными, что не возникнет «пробок» во время создания тестовой загрузки, клиентскую машину сделали самой мощной (она должна быть как минимум такая же по мощности, как и серверы).
используемое программное обеспечение
Мы использовали следующее программное обеспечение:
- операционная система: Debian GNU/Linux 3.1 'sarge';
- база данных: MySQL v. 5.0.7beta-1;
- сервер приложений: JBoss v.4.01sp1 (Java2 SDK 1.4.2_08);
- клиент: ECPerf suit 1.1 (Java2 SDK 1.4.2_08).
На всех машинах был использован Debian 'sarge'. Доступная память для Java была выставлена в 384Mb.
ECPerf и его настройка
ECPerf – это средство тестирования Enterprise JavaBeans (EJB), которое используется, чтобы определить возможность масштабирования и производительности серверов и контейнеров J2EE. Этот тест сильно нагружает возможности EJB-контейнеров по манипулированию управлением памятью, организацией связного пула, пассивацией/активацией и кэшированием. ECPerf первоначально разрабатывался в Sun Microsystems, но на данный момент разрабатывается и поддерживается корпорацией SPEC, которая распространяет данный продукт под названием SPEC-jAppServer2004.
Конфигурация ECPerf: во время подготовки эксперимента была определена следующая нагрузка как приносящая наилучшую производительность: txRate = 5, runOrderEntry = 1, runM fg = 1. Нагрузка эквивалентна 40 потокам: 25 потоков для упорядоченного поступления и 15 потоков для запланированных действий.
Установки режимов:
- запуск: rampUp = 480, 8 минут;
- устойчивый: stdyState = 600, 10 минут;
- выключение: rampDown = 180, 3 минуты.
алгоритм тестирования
Приведенный ниже псевдокод описывает алгоритм тестирования, используемый при исследованиях. Приведем краткое описание.
Каждая из система установлена и запущена; затем для каждого параметра в красном или в синем списках мы устанавливаем определенное значение. Далее идет очистка памяти и базы данных, отключение своппинга и перезапуск сервера приложений. Результаты сохраняются для каждого отдельного запуска для дальнейшего анализирования.
for(система установлена) {
запуск системы;
for(меняем параметр) {
меняем значение параметра;
new average; //среднее время
for(int i = 0; i++; i < 3) {
очищаем память;
очищаем базу данных;
отключаем своппинг;
average += avg(run_ecperf());//заносим результат
}
save_tuple(kernel, parameter, value, average);//сохраняем результаты
}
}
Значения параметров VMM изменялись два, три или четыре раза в зависимости от типа параметра. Также были проведены тесты с установками по умолчанию. Разделы свопинга были отключены на время проведения тестирования, что должно было привести к увеличению производительности.
результаты и анализ
На рисунке 1 показаны все результаты, полученные во время измерений. Они показывают среднюю производительность по ECPerf, которая представленна в количестве операций за минуту в бизнес приложениях. Наибольшие и наименьшие значения производительности брались по три раза, в то время как тестирование при установках по умолчанию проводилось по 10 раз. Среднее увеличение производительности по сравнению со стандартными установками составило 5,19%, а среднее падение производительности в результате непреднамеренного изменения конфигурации составило -8,73%. Падение производительности не относится к параметру min_free_kbytes, который, если установлен слишком большим, останавливает работу ОС.
Рис. 1. Общие результаты.
Надо отметить, что ядра Debian, на наш взгляд, более чувствительны к изменениям в конфигурации. Семейство ядер SUSE показало схожую производительность в двух конфигурациях: в измененной и в конфигурации, идущей вместе с SUSE. Также семейство ядер, поддерживаемое Коном Коливасом (Con Kolivas) продемонстрировало схожее падение производительности на всех уровнях – цена, которую приходится платить за улучшение пользовательской интерактивности и за переключение контента. Референсный тест (семейство ядер 2.4) продемонстрировал значительно более медленные результаты, чем его эквивалент на семействе ядра 2.6. Семейство ядер Эндрю Мортон (Andrew Morton), которое является экспериментальной площадкой для новых фич, продемонстрировало увеличение производительности относительно серий 2.6.11, что в последствии нашло свое отражении в основной линейке 2.6.14, а затем с доработкой и в 2.6.15. Данные три ядра на наш взгляд ведут себя лучше в базовой конфигурации.
Мы утверждаем, что 5%-ное увеличение производительности - достаточно важный результат, считая тот факт, что это вызвано изменением только одного значения в параметрах VMM. В нижестоящей таблице представлены результаты для каждого ядра.
Таблица 1. Максимумы и минимумы производительности для различных ядер, %.
| Ядро | Улучшение | Ухудшение |
| 2.6.11.12-acDebian 2.6.8-2Debian 2.4.26Fedora 2.6.11-1.13692.6.12.3-ck2.6.13-rc3-mmDebian 2.6.11SuSE 2.6.11.4(1)SuSE 2.6.11.4(2)Vanilla 2.6.12.3Vanilla 2.6.14.3Vanilla 2.6.15-rc5 | 2.9514.969.894.256.023.05.292.703.614.042.453.16 | -4.43-20.93-10.88-5.77-5.59-7.34-20.00-5.32-6.03-3.27-7.15-8.04 |
| Среднее | 5.19 | -8.73 |
обработка результатов
На рисунке 2 для каждого ядра показаны число непройденных тестов и среднее отклонение от результатов. Они довольно невелики, поскольку общее количество тестов включает: 11 параметров ядра * 3 значения * 3 ECPerf-теста = 99. Причиной провала большинства непройденных тестов была установка параметра «min_free_kbytes» равным 256 Мб, который забирал часть памяти у сервера приложений. Поскольку вдруг часть памяти становилась недоступной, JVM не могла запуститься, таким образом провалив тест. Предположение о предварительном разделении параметров VMM на красные и синие группы оказалось частично верным, хотя наихудшие показания продемонстрировало изменение параметра min_free_kbytes.
Самая верхняя линия на рисунке 2 показывает среднее эталонное отклонение для тестов. Можно отметить, что ядра Debian имеют большее отклонение, в то время как худшее у ядра Con Kolivas'a.
Рис. 2. Число непройденных тестов и среднее отклонение результатов.
Результаты общего анализа чувствительности представлены на рисунке 3. Они показывают параметры ядра, которые имеют наисильнейшее, но не обзательное лучшее влияние на производительность J2EE-системы. Эта круговая диаграмма была получена следующим образом: суммировалась разница производительности каждого ядра при определенных настройках, так было проделано для каждого параметра, затем по этим данным была построена диаграмма. Вот формула:
sensivity = ?(stdev(параметр, ядро)) (1)
Видно, что dirty_expire_centisecs и min_free_kbytes имеют наибольшее влияние на производительность. Изменение остальных параметров воздействует на производительность в меньшей степени. Более детально это показано на рисунке 4.
Попытка определить, какая из настроек VMM реально дает более лучшую производительность, отображена на рисунке 5. Задача нетривиальна, поскольку не было явного лидера – каждое ядро имело свои «выигрышные» настройки. Чтобы обойти это затруднение, результаты для каждого ядра были отсортированы по производительности при работе с бизнес-приложениями и каждому из 33 параметров было сопоставлено значение от одного (худшая производительность) до 33(для демонстрации лучшей производительности). Затем соответствующие параметры и их значения были сгруппированы по семействам ядер.
Рис. 3. Общая чувствительность разнообразных настроек VMM.
Рис. 4. Чувствительность различных настроек VMM и ядер.
Рис. 5. Степень воздействия параметров на производительность.
Результаты были разделены на три категории: «возможно позитивные», «неопределенные», «негативные». Установки в группе «возможно позитивные» больше похожи на настройки, которые могут увеличить производительность, а настройки группы «негативные» значительно ухудшают производительность. Оставшиеся настройки были протестированы, чтобы определить, какие из них и для каких задач дают большую производительность.
проделанная работа
Исследование зависимости производительности J2EE в основном имеет дело с уровнем программного обеспечения, который лежит ниже самих приложений, то есть с сервером приложений. Две наиболее известные работы:
- Gorton, I., Liu, A., Brebner, P.: Rigorous Evaluation of COTS Middleware (Technology IEEE Computer Mar (2003) 50-55);
- Cecchet, E., Marguerite, J., Zwaenepoel, W.: Performance and Scalability of EJB Applications (Proc. of 17th ACM Conference on Object- Oriented).
Сейчас много предпринимается для исследования JVM, хотя основные темы - общая оптимизация работы и сборка мусора. Также более ранние исследования авторов касались воздействия методов ввода параметров на производительность EJB-приложений.
выводы и будущая работа
Используя ECPerf-тест, мы протестировали многие семейства ядер Линукса, чтобы определить, влияют ли изменения настроек VMM на производительность J2EE-приложений. Параметры, которые влияют на производительность, подверглись анализу.
Мы аргументировали, что производительность изменилась более чем на 5% при изменении всего лишь одного параметра VMM. Это важно, и на это нельзя закрывать глаза, особенно имея дело с системами, чувствительными к производительности.
Есть планы для более детального исследования, которое будет включать различные параметры оптимизации и большее количество серверных приложений: WebSphere Community Edition, WebSphere Enterprise Edition. Мы также планируем оценить влияние различных процессов и планировщиков ввода-вывода на производительность J2EE.
Александр Уфимцев, alexu@ucd.ie, Елена Кучеренко, alena_kucharenka@tut.by, Лиам Мерфи, Liam.Murphy@ucd.ie, Лаборатория исследования производительности, Школа вычислительной техники и информатики, Колледж при университете Дублина.Перевод Дмитрия Канаева.Авторы с благодарностью приняли помощь от «Informatics Research Initiative of Enterprice Ireland».
Сетевые решения. Статья была опубликована в номере 10 за 2006 год в рубрике лабораторная работа
