SPEC и SIPEW 2008: тесты для профессионалов
Многие наши читатели знакомы с Standard Performance Evaluation Corporation (SPEC), некоммерческой организацией, поставившей своей целью создать релевантные и реалистичные стандартные тесты. SPEC располагается в городе Варрентон (Warrenton, штат Вирджиния) и сегодня насчитывает более 60 членов (официальный сайт — http://www.spec.org). Среди членов присутствуют знаменитые университеты и крупные игроки в компьютерной индустрии, желающие помочь в разработке и развитии тестов, которые рано или поздно будут использоваться для оценки и тестирования продуктов. Организация не выносит рекомендаций, но предоставляет результаты тестирования публике.
Подразделения SPEC
SPEC разделяется на три отдела, которые отвечают за тесты системного уровня, высокопроизводительные вычисления (HPC) и графику. В портфолио присутствуют тесты процессоров (SPEC CPU2006, CPU2000), профессиональные тесты графической производительности (SPECviewperf and SPECapc workloads), высокопроизводительных вычислений (SPEC MPI2007), клиент/серверные тесты на основе Java (SPECjAppServer, SPECjbb, SPECjms, SPECjvm), различные требования к серверам, а также тесты для определения эффективности энергопотребления (SPECpower_ssj20). Ни один из этих тестов не ориентируется на потребительский уровень; они предназначены для сравнения производительности в профессиональном и корпоративном окружениях.
SPEC предоставляет инструменты, которые позволяют эффективно дифференцировать системы на честной основе и вместе с тем дают возможность сфокусироваться на отдельных характеристиках системы. Тесты базируются на популярных приложениях и программах, являющихся стандартом индустрии, которые были портированы на распространённые платформы. До запуска теста исходный код компилируется для целевой системы, используя оптимизированные компиляторы и специфические настройки, позволяющие достичь максимальной производительности на целевом окружении.
Графическое тесты SPECapc и SPECviewperf можно скачать бесплатно — мы давно используем SPECviewperf для оценки производительности видеокарт OpenGL- тесты CPU и системного уровня необходимо покупать. Их цена зависит от $50 до $2000, в зависимости от усилий, потраченных SPEC на разработку. Есть немалые скидки для некоммерческих организаций и образовательных учреждений, что сокращает ценовой диапазон с $50 до $900.
Результаты SPEC для профессионалов
Членам организации предлагается внести результаты тестов в SPEC, после чего они будут проанализированы и опубликованы на сайте (например, вы можете посмотреть результаты SPEC CPU2006, а также страницу внесения результатов). Поскольку SPEC является самой признанной организацией профессионального тестирования, компании, такие как AMD или Intel, всегда с большим желанием публикуют результаты своих самых производительных решений в SPEC. В итоге, эти значения можно считать публичными, их признают многие специалисты, принимающие решения о закупке.
Мы посетили так называемый семинар SPEC SIPEW в немецком Дармштадте, где, в том числе, обсуждалась проблема диспетчеризации серверных ферм, а также тест эффективности энергопотребления SPECpower_ssj2008.
SIPEW 2008
SIPEW расшифровывается как «SPEC International Performance Evaluation Workshop», и семинар SIPEW 2008 проводился 27 и 28 июня в Дармштадте, как раз после международной конференции SPEC, длившейся почти неделю. Наше издание получило приглашение на это мероприятие, с которым мы были не знакомы, поэтому мы решили посетить семинар и ознакомиться с ним очно.
 |
Нажмите на картинку для увеличения.
Основная цель семинара SIPEW 2008 заключается в создании условий для производителей «железа» и программного обеспечения, которые позволили бы им общаться друг с другом, а также и с инженерами тестирования. Почти сотня участников подчеркнули значимость мероприятия, учитывая его высоко профессиональную природу и глубокую техническую направленность, позволяя разобрать тестирование «по полочкам». При регистрации все участники получили книгу на тему семинара: «Оценка производительности: исходные параметры, модели и тесты» (Performance Evaluation — Metrics, models and benchmarks).
 |
Нажмите на картинку для увеличения.
Большая часть книги написана научным языком и вряд ли будет понятна читателям, не считающими себя специалистами в области статистики, математики, программных архитектур и проблем, связанных с тестами. Однако пленарные доклады семинара, связанные с практическими тестами, будут интересны более широкой аудитории. Два пленарных доклада нас весьма заинтересовали, а именно на тему диспетчеризации (scheduling) серверных ферм и теста SPEC по эффективности энергопотребления SPECpower_ssh2008, который был выпущен в конце 2007 года.
Диспетчеризация отдельных серверов
Данный доклад являлся одним из пленарных на SIPEW 2008, он был посвящён результатам вероятностного анализа серверных ферм. А именно, профессор Мор Харчол-Балтер (Mor Harchol-Balter), глава отдела аспирантуры факультета информационных технологий Университета Карнеги-Меллона, обсудила диспетчеризацию серверных платформ по сравнению с отдельными серверами.
Презентация профессора детально рассказывала о разных подходах к диспетчеризации в условиях короткое время отклика — разные технологии маршрутизации и распределения нагрузки на разные серверы могут привести к существенно различающейся производительности. В качестве стартовой точки можно вернуться к тому, как Windows 3.1 реализовывала многозадачность по сравнению с современными операционными системами, такими как Windows 2003/XP или Vista, поскольку распределение нагрузки по нескольким серверам, по своей сути, очень близко к многозадачности. Во время Windows 3.1 использовалась кооперативная (cooperative) многозадачность, опиравшаяся на отдельные процессы без приоритезации, то есть поток часто не отдавал управление обратно операционной системе, пока не выполнял свою работу. Таким образом, хотя разные потоки и не требовалось синхронизировать, отдельные процессы могли «повесить» всю систему.
Диспетчеризация задач имеет значение
Современные операционные системы построены на вытесняющей (preemptive) многозадачности, когда ядро операционной системы отвечает за привязывание потоков к доступным процессорным ресурсам. Это можно выполнять путём простого распределения, например, по кругу, или на основе политики приоритетов. Если для систем с одним ядром результаты вполне предсказуемы, то при переходе на несколько ядер приоритезация задач становится не такой простой. После добавления интерфейсов появляется задержка, именно поэтому профессиональные операционные системы учитывают вычислительные ресурсы (node-aware), то есть они могут распределять потоки в зависимости от доступных процессорных сокетов и ядер, чтобы избежать лишнего трафика. Вполне очевидно, что распределение работы в серверных фермах, в которых задействовано большое количество систем, подразумевает больше вариантов для маршрутизации задания и оптимизации политик распределения, чтобы получить максимальную производительность.
Политики диспетчеризации для отдельных серверов
 |
Знаете ли вы время отклика для распространённых политик диспетчеризации? Нажмите на картинку для увеличения.
Сначала Мор Харчол-Балтер рассказала о разных политиках диспетчеризации отдельных серверов.
- FCFS (First-Come-First-Served, не вытесняющая). В данном случае входящие работы распределяются по принципу «первый пришёл, первый выполнился», нагрузки привязываются к доступным вычислительным ресурсам.
- PS (Processor-Sharing, вытесняющая). Данная политика очень близка к тому, что мы подразумеваем под вытесняющей многозадачностью. Все входящие работы распределяются равномерно по доступным вычислительным ресурсам.
- SJF (Shortest-Job-First, a.k.a. SPT, не вытесняющая). Эта политика всегда сначала выполняет те нагрузки, которые можно завершить быстрее всего. Однако задачи будут выполняться до тех пор, пока они не будут завершены.
- SRPT (Shortest-Remaining-Processing-Time, вытесняющая). В данной политике приоритет отдаётся коротким нагрузкам, которые распределяются по доступным вычислительным ресурсам. Как и в случае PS (Processor-Sharing), нагрузки можно переключать.
- LAS (Least Attained Service, вытесняющая). Данный способ распределяет нагрузки равномерно по вычислительным ресурсам, чтобы создать сбалансированное их использование.
 |
А вот и результат: на крупных задачах время отклика политик FCFS и SJF увеличивается, причём весьма существенно. Вполне понятно, что не вытесняющая диспетчеризация хуже. Нажмите на картинку для увеличения.
Политики диспетчеризации для серверных ферм
Открытые и закрытые системы
На следующем этапе профессор рассмотрела техники диспетчеризации серверных ферм, где маршрутизация является весьма важной задачей. Для подобных применений крупного масштаба очень важно сначала подумать о типе нагрузки, под которой будет работать ваша система. Рассмотрим отличие открытых систем от закрытых. В открытых системах ваше решение будет работать над задачами, которые очень предсказуемы; представьте себе web-сервер или ферму web-серверов. В таком случае очень важно разработать и проанализировать идеальную стратегию диспетчеризации и распределения, чтобы снизить время отклика и максимально увеличить производительность. Система называется открытой, поскольку здесь могут присутствовать разные задачи от разных источников, и результаты будут тоже разные. Однако в закрытой системе распределяются менее предсказуемые задачи, поскольку они являются результатом от предыдущих задач, и для определения способа дальнейшей обработки задач необходимо их проанализировать.
 |
Если закрытая система будет работать с разнообразной и непредсказуемой нагрузкой, то политика диспетчеризации задач будет давать не такую большую разницу, как в случае с открытой системой. Нажмите на картинку для увеличения.
На следующем примере ферма web-серверов используется для создания окружения, в котором входящие задачи распределяются по системам. Все серверы работают по принципу вытесняющего использования процессора, как и большинство многозадачных ОС сегодня. Основной вопрос заключается в том, как распределить нагрузку на серверы, чтобы получить минимальное время отклика, отсюда лучшую производительность. В данном примере решение, определяющее политику маршрутизации (см. иллюстрацию ниже), должно быть осведомлено о нагрузке, чтобы принять решение о технике диспетчеризации (см. ниже).
 |
Нажмите на картинку для увеличения.
Пуассоновский процесс, который используется в этом примере, является вероятностным, в котором события происходят непрерывно и независимо один от другого. Хорошо известным примером можно назвать радиоактивный распад атомов. Запросы HTTP относятся к пуассоновским процессам. Каковая же будет разница в производительности в зависимости от разных техник диспетчеризации?
Политики диспетчеризации задач для серверных ферм
Мор Харчол-Балтер указала четыре возможные техники диспетчеризации задач.
 |
Нажмите на картинку для увеличения.
- Random. Входящие задачи распределяются на случайные системы без какой-либо политики.
- Join-Shortest-Queue. В данном случае задачи направляются на сервер, у которого меньше всего задач в очереди. Эта техника требует предварительного анализа серверных систем и обычно подразумевает политику «первый пришёл, первый выполнился».
 |
Нажмите на картинку для увеличения.
- Least-Work-Left. Подход похож на предыдущий (JSQ), но он учитывает задание, которое нужно выполнить. Первой получают следующее задание системы с меньшей действительной нагрузкой. Задания обычно выдаются диспетчеризацией в зависимости от их нагрузки.
- Size Interval Splitting. Этот подход распределяет нагрузку равномерно по всем доступным клиентам, что позволяет достичь хорошего баланса нагрузки между всеми серверами, но увеличивает время отклика.
 |
Как видим, техника JSQ (Join-Shortest-Queue) обеспечивает самое короткое время отклика над случайной техникой (Random) и Least-Work-Left, где время отклика увеличивается при повышении непредсказуемости нагрузок. Нажмите на картинку для увеличения.
Вообще, тема диспетчеризации горячо обсуждается уже на протяжении более 40 лет. Вполне очевидно, что здесь есть разные стратегии, которые могут или не могут подходить для отдельных условий. Самый важный параметр, конечно, это сама нагрузка, и её анализ в закрытых и открытых системах. Выбор правильной политики и «железа» выполняется уже вторым шагом.
Тестирование эффективности энергопотребления с помощью SPECpower_ssj2008
Энергопотребление в настольных системах никогда не доставляло особых проблем, по крайней мере, пока Intel не достигла совершенно неразумного уровня с процессорами Pentium 4 и Pentium D, но в серверных фермах проблема остро стояла многие годы. Питание требуется не только для работы серверов; увеличение энергопотребления центров обработки данных и серверных ферм приводит к тому, что всё больше энергии уходит на кондиционирование воздуха. Компьютерные решения с высокой плотностью и высокой производительностью должны работать эффективно, поэтому SPEC решила разработать тест эффективности энергопотребления. SPECpower_ssj2008 был выпущен в конце 2007 года, он соотносит производительность и энергопотребление, используя тест Java SPECjbb2005.
 |
Нажмите на картинку для увеличения.
SPEC SPECpower_ssj2008 базируется на тесте SPECjbb2005, который использует Java. Его можно использовать на системах любого вида, поэтому решение весьма гибкое. Однако тестовый пакет был серьёзно модифицирован, поэтому результаты SPECpower_ssj2008 и SPECjbb2005 сравнивать нельзя.
 |
Нажмите на картинку для увеличения.
SPEC называет тестовую систему SUT (System under Test), а мониторинг осуществляется с помощью системы CCS (Control & Collection System).
Для отслеживания энергопотребления и правильной работы SPECpower_ssj2008 на второй системе требуется датчик энергопотребления. Как можно видеть, тест состоит из серверной части для SUT (ssj_2008 JVM) и клиентской части ssj2008 Director. CCS начинает тест и снимает все измерения с помощью ваттметра и термометра.
Калибровка производительности и измерения
Сначала ssj Director запускает анализ пика транзакций, чтобы откалибровать тестовую систему. После этого проводятся тесты под пиковой нагрузкой, а затем и при снижении нагрузки, что видно по следующей иллюстрации.
 |
SPECpower_ssj2008 отслеживает энергопотребление при 100% нагрузке, а затем снижает нагрузку шагами в 10% вплоть до режима бездействия. Нажмите на картинку для увеличения.
Для калибровки тестовой системы ssj2008 Director запускает по одной задаче на вычислительное ядро, определяя пиковую производительность теста. Затем производятся тесты при 100% нагрузке, после чего нагрузка снижается шагами по 10% вплоть до активного режима бездействия (он соответствует системе, ожидающей работу). SPEC решила пойти на такой шаг, поскольку серверы обычно работают на низких нагрузках, но никогда не уходят в «настоящий» режим бездействия. Чтобы снизить количество ошибок, измерения начинаются через несколько секунд после старта задания, а также заканчиваются на несколько секунд раньше теста. Это сделано, чтобы на результаты измерений не влияли переходные состояния систем.
Производительность на ватт для 0-100% нагрузки
 |
Для каждого прогона SPECpower_ssj2008 делит суммарную производительность на среднее энергопотребление. Впрочем, доступен и более детальный анализ. Нажмите на картинку для увеличения.
SPECpower_ssj2008 рассчитывает производительность на ватт следующим образом: он использует сумму результатов производительности в операциях в секунду, после чего делит её на среднее энергопотребление. И так для каждого из 11 тестовых прогонов. Результат отображается как количество операций ssj2008 на ватт.
Очевидно, учитывая нагрузку и требования к тестовой системе, что данный тест не предназначен для домашнего выполнения. Но перед нами первый стандартный тест в индустрии подобного рода, который, к тому же, использует ядро популярного теста Java. Поскольку многие корпоративные приложения построены на Java VM, результаты производительности Java на ватт для индустрии значат немало. Впрочем, несмотря на представление довольно полной картины, это явно не единственный инструмент, который следует учитывать при приятии важного решения.
Заключение
Количество информации во время семинара SIPEW 2008 оказалось просто огромным. Лабораторные работы по грядущим тестам от SPEC были вполне ожидаемыми, однако и презентации оказались детальными и интересными. В нашей статье мы рассмотрели две темы семинара, которые, как нам кажется, будут наиболее интересны нашим читателям и широкой аудитории, а именно эффективная диспетчеризация задач в корпоративном окружении, а также тесты эффективности энергопотребления систем корпоративного класса.
Информация на семинаре и в книге SIPEW 2008, касающаяся оценки производительности, носит явно научный характер, поэтому она вряд ли будет воспринята большинством администраторов, руководителями ИТ-отделов и энтузиастами, хотя практические рекомендации весьма интересны. Семинар нацелен на немногих сотрудников внутри крупных корпораций, которые занимаются новыми способами оценки производительности и эффективности корпоративных систем, чтобы обеспечить лучшее соотношение цена/качество закупок и лучшую отдачу от инвестиций.
Итог для наших читателей будет таков, что повышение сложности системных решений, особенно серверных ферм, требует всё большего вложения в аналитику и исследования. У SPEC и членов организации есть немало информации по стратегиям планирования нагрузки, да и недавно был представлен тест SPECpower_ssj2008, весьма любопытное решение для оценки эффективности энергопотребления серверных систем Java. Впрочем, SPEC не может дать детальной оценки в ваших собственных условиях, поскольку ваши приложения и системы могут существенно отличаться. К сожалению, новые тесты не относятся к классу «нажал, прогнал тест и получил результат», и для получения релевантного результата нужно провести широкий набор подходящих тестов.
