Как повысить производительность бесплатно, без регистрации и смс

Привет! Я работаю интерном в Санкт-Петербургском центре разработок ЕМС и хочу дать студентам пару советов о построении будущей карьеры, а также рассказать про задачи, которыми занимаюсь в компании. В этом году за одно из своих решений я получил награду Bright Internship Award как лучший стажёр Центра, и мне интересно получить обратную связь по достигнутым результатам. Эта статья может быть интересна тем, кто занимается тестированием производительности систем.

Немного лирики (или как я перестал бояться и попал на стажировку)

История моего знакомства с ЕМС берет начало с похода на IT-выставку для молодых соискателей в сфере информационных технологий — Bit-Byte. Я прошел по всем корпоративным стендам, заполнил десятки весьма сомнительных листочков и взял несколько визиток. Когда хочется поскорее начать обретать опыт работы по специальности и получать за это деньги, то не особо задумываешься о месте для карьерного старта.

Многие компании утверждают, что к ним приходят студенты, осведомленные о ее месте на IT-рынке, о ее продуктах, клиентах и т.д. Но, основываясь на своем личном опыте, могу сказать, что это не так. 90% студентов просто рассылают резюме на все возможные позиции в несколько компаний, даже не меняя текст под конкретную вакансию. И я не был исключением: придя домой, я разослал свое резюме на все e-mail адреса, которые были на взятых мной визитках. Мне всегда казалось, что это в порядке вещей: сотни человек ежемесячно шлют письма с откликами, десятки приглашаются на собеседования, а нанимаются лишь единицы. Это заставляет тебя охватывать в своей рассылке как можно больший диапазон компаний, чтобы повысить свои шансы быть зачисленным в штат. На следующий день я уже решал различные тестовые задания, а еще через неделю меня пригласили на несколько собеседований.

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

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

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

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

Въезд про оценку производительности

Моя работа в компании связана с оптимизацией производительности продукта ЕMC PowerPath. В общих чертах, это программное обеспечение, работающее на серверах в SAN, которое оптимизирует использование путей в сетях хранения данных на базе FC, iSCSI и FCoE для обеспечения предсказуемого, масштабируемого и согласованного доступа к информации. Данное ПО обеспечивает эффективное использование всех каналов передачи данных и устраняет необходимость в нескольких отдельных решениях по управлению путями для разнородных операционной системы.

Оптимизация всегда затрагивает множество аспектов разработки ПО, ты должен хорошо понимать функционал продукта, уметь его протестировать и автоматизировать выполняемые действия. Поначалу было достаточно трудно вникнуть в логику продукта, и процесс адаптации к существующему коду занял достаточно долгое время. Пришлось довольно быстро освоить Perl, средства для профилировки различных операционных систем, shell, стандартные утилиты Windows и Unix.

В данном конкретном случае, тестирование состоит из динамической верификации поведения программы на конечном наборе тестов, сама программа представляется в виде «черного ящика». При этом тесты выбираются из обычно выполняемых действий прикладной области и обеспечивают проверку соответствия ожидаемому поведению системы. Очень часто при разработке программного комплекса приходится сталкиваться с одной из двух проблем. Либо качество разработанного продукта ниже минимальных требований: либо затраты на тестирование превосходят все разумные пределы. Для того, чтобы уменьшить затраты на опробование поведения программы в различных средах, необходимо максимально автоматизировать этот процесс.

Именно за создание средств автоматизации тестирования EMC PowerPath и встроенные в ОС системы multipathing я и получил награду EMC Bright Internship Award. Этот подход к тестированию производительности позволил значительно повысить производительность продукта за счёт выявления проблем (узких мест), решение которых обеспечило существенное увеличение производительности (в частности, на платформе на AIX (> 30%)). Суть в следующем: измерение пропускной способности базовых утилит ОС проводится с целью сравнения полученных вычислений с результатами для программного продукта от EMC, развернутого с различными физическими и программными компонентами подсистемы. Делается это без лишних временных затрат, автоматизировано и унифицировано. Нужен был комплекс, который являлся бы высокоэффективным и универсальным с точки зрения возможности применения для автоматизации тестирования на любой операционной системе (AIX, ESXi, RHEL, WS), а также не требовал бы значительных трудозатрат для своего применения. Далее я расскажу о том, как я это сделал. 

Что было сделано

Для начала, дадим определение ПО для генерации данных (I/O benchmarks) — это приложение, которое позволяет запустить синтетический тест дисковой и сетевой подсистем, как для одиночных, так и кластерных систем. Оно может использоваться в качестве базового инструмента для лабораторных исследований и поиска неисправностей. Может быть легко настроено для воспроизведения нагрузки (имитации поведения) от многих популярных приложений путём задания тестовых шаблонов.

Для тестирования механизма балансировки, используемого в продукте, с точки зрения оценки его производительности я использую три различных программных продукта генерации блоков данных: Iometer, Iorate и Vdbench. Их сравнительные характеристики даны в таблице:

Одним из ключевых параметров является возможность генерации случайных блоков данных, так как корпорация EMC производит СХД, поддерживающие технологию дедупликации. Такие системы хранения сохраняют только ссылки на повторяющиеся блоки (например, по 4 кбайт), что осуществляется гораздо быстрее записи целого блока. Исходя из этого, нагрузка из повторяющихся данных для некоторых СХД не позволяет получить адекватные результаты производительности, и в этом случае используется Vdbench.

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

• UIO (Uniformed I/O) — тесты с фиксированным размером данных, каждый из которых основан только на одном паттерне.
• DBSIM (DataBase SIMulation) — тесты, основанные на смешивании различных паттернов в определенном соотношении, чтобы эмулировать работу реальной бизнес-системы, например, OLTP. При таком подходе, блоки различного размера отправляются по очереди.

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

• Размер блока данных;
• % чтения/записи;
• % случайных/последовательных I/O, модель доступа к диску при чтении или записи блока. При последовательной модели доступа к диску, запись и чтение происходят значительно быстрее, так как при этом не осуществляется операция произвольного доступа.

Время произвольного доступа — среднее время, за которое винчестер выполняет операцию позиционирования головки чтения/записи на произвольный участок магнитного диска. Актуально только для устройств, основанных на принципе магнитной записи.

В качестве пояснения сказанного выше, в таблице приведен список UIO тестов для тестирования производительности:

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

Кроме паттерна, каждый тест имеет несколько основных характеристик, некоторые из которых являются неотъемлемыми:

• Run time — время, в течение которого, все полученные результаты вычислений будут влиять на финальный результат. Обычно измеряется в секундах.
• Warm up time — время прогрева, в течение которого результаты вычислений не входят в финальный результат. Измеряется в секундах.
• Pause time — время простоя между тестами. Измеряется в секундах.
• IO rate — максимально возможная скорость передачи данных, измеряется в операциях чтения/записи в секунду (IOPS), по умолчанию без ограничений.

Значения этих параметров вносятся в конфигурационный файл и не изменяются в течение запуска.
Каждая из трех программ, — Iometer, Iorate, Vdbench, — формирует один или несколько выходных файлов, содержащих, кроме полезной для дальнейшего разбора информации, и различные второстепенные данные о запуске. Поэтому необходимо разработать скрипты, которые позволят парсить полученные файлы с целью извлечения и преобразования данных в нужный унифицированный формат.

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

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

Конфигурация «лаборатории» для исследования

Остановимся подробней на организации «лаборатории» для исследования:

Стандартная конфигурация системы

Host side:
За исключением AIX с проприетарными хостами от IBM, используются физические машины Dell PowerEdge R710:
Memory: 11898Mb RAM
Processor: Intel® Xeon® CPU E5530 @ 2.40GHz
CPU: 2394.172 MHz
Cache Size: 8192 KB
с 2 физическими сокетами, 8 физическими ядрами, 8 hyper-threading ядрами.

Остальные настройки хоста, в замисимости от тест кейса:
OS: ESXi, RHEL, Windows Server, AIX
Number of cores: 4/8/16
Logical Units: 4/8/16
Logical Unit size: 5GB (Диски малого объема для максимального IOPS)
Threads per LU: 64 for 4 LU, 32 for 8 LU, 8 for 16 LU, 4 for > 16LU

Storage side:
EMC XtremIO, 1 X-Brick configuration
EMC Symmetrix VMAX
EMC VNX

SAN:
Выделенный FC Switch, 8Gb Fibre Channel ports

Стандартные настройки фабрики с точки зрения количеcтва FC адаптеров

Jamming конфигурация

Jamming конфигурация для тестирования используется для симуляции «узких» мест в SAN. Конкретно на этой иллюстрации используется ОС Windows Server, хотя по факту она может быть любой. В системе используется два хоста: один с предустановленным PowerPath (потом и MPIO), на нем производятся вычисления производительности; другой – нагрузочный. Каждый сервер соединён по различным SAN с СХД. Красным отмечен загруженный путь к данным, зелёным – свободный.

Адаптивная политика PowerPath определяет степень загруженности пути и позволяет перераспределить нагрузку на свободный. Подобная конфигурация позволяет создать условия, которые вполне могут возникнуть в реальной лаборатории у заказчиков (выйдет из строя определенный путь, неграмотная конфигурация, один общий SAN на несколько серверов и тд). Условия, в которых нативный multipathing будет функионировать со скоростью самого медленного пути, а PowerPath должен показать существенно более высокий IOPS.

Результаты представляются в виде графиков, которые строятся с помощью программы Gnuplot. Она имеет собственную систему команд, умеет работать в режиме командной строки и выполнять скрипты, читаемые из файлов. Gnuplot способен как сохранять графики в виде файлов различных графических форматов (командный режим работы), так и выводить их на экран.

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

Конфигурация тестирования

Остановимся более подробно на конфигурации тестирования. Немаловажным параметром при старте сценариев опробования является количество запусков. Зачастую, при тестировании PowerPath и NMP возникает проблема отклонения полученного значения производительности от средней величины, выраженное в процентах. В данной работе было решено принять за допустимое отклонение величину, меньшую или равную 5%. Если разброс от среднего значения по всем запускам превышает установленную планку, то мы не можем проводить оценку пропускной способности, а такие тесты требуют дальнейшего анализа и повторного воспроизведения.

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

По оси «y» отложена величина отклонения конкретного запуска от среднего значения в % (пропусная способность). Ориентируясь на ось «x», мы видим, какой именно версии PowerPath или NMP (Native Multipathing), встроенное средство балансировки) принадлежат данные результаты. На графике отчетливо видно, что в некоторых тестах существуют запуски с отклонением более 5%, а некоторые приближаются к данному значению. Подобные опробования требуют дальнейших исследований.

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

• Время выполнения (run time);
• Время прогрева (warm up time);
• Время простоя (pause time).

Для того, чтобы обеспечить качество и релевантность результатов тестирования, была проделана огромная аналитическая работа. В конфигурациях, в которых наблюдается большой разброс результирующих данных, были запущены тесты с длительным временем выполнения, а значения пропускной способности сохранялись в лог с периодичностью в 10 секунд. С помощью статистического анализа полученных результатов можно грамотно подобрать различные временные интервалы и количества запусков для конкретных тестов в заданной конфигурации. Данные интервалы можно просуммировать и получить временные промежутки любой длительности. По таким суммам рассчитывается относительное среднеквадратическое отклонение (RSD или relative standard deviation, его еще называют коэффициентом вариации), которое характеризует однородность данных, что является ценной статистической характеристикой. По величине коэффициента вариации можно судить о степени вариации признаков совокупности. Чем больше его величина, тем больше разброс относительно среднего значения, тем менее однородна совокупность по своему составу и тем менее представительна средняя. Коэффициент вариации (1) это отношение среднеквадратического отклонения (2) к среднеарифметическому (4), выраженное в процентах. Среднеквадратическое отклонение, в свою очередь, может быть найдено как корень из дисперсии (3). N — количество независимых испытаний.

В отличие от отклонения от среднего, на которое мы обращали внимание при построении гистограмм, RSD позволяет наиболее точно представлять рассеивание признака и его величину относительно самих значений (относительный показатель, а не абсолютный). Теперь подберем временной интервал для конкретного теста и будем считать его приемлемым, если значение RSD для всех таких интервалов меньше или равно 5%.

После проведенных вычислений и перераспределения временных интервалов, повторим тестирование и построим графики с помощью того же Perl-скрипта. Величина отклонения от среднего заметно уменьшилась и результаты тестирования стали наиболее точно отражать реальную картину работоспособности ПО.

В результате

Подведем итоги проделанной работы:

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

Для себя могу сделать вывод, что быстрое, прозрачное и унифицированное проведение автоматического тестирования разрабатываемого продукта позволяет ему развиваться с существенно более быстрой скоростью. В частности, благодаря такому подходу, мы смогли увеличить производительность EMC PowerPath на AIX более, чем на 30%.

Напутствие для студентов

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

Автор: zolotukhin_ru

Источник