Автор: Лубанец Александр, СПбГТУ, 2000
MOSIX-кластер |
1.2.2 Алгоритмы разделения ресурсов 1.4.1 Механизм представитель/удаленный 2.1 Тестирование производительности 2.4 MOSIX-кластер в ИВЦ СамГТУ |
СПбГТУ, 2000 |
Технология MOSIX |
MOSIX - системное программное обеспечение и одноимённая технология для поддержки кластерных вычислений разработанная в университете Hebrew University (Иерусалим, Израиль). Данная технология характеризуется использованием уровня ядра для основных модулей, адаптивных алгоритмов распределения ресурсов для высокой производительности, низких накладных расходов по масштабированию и простого в использовании управления кластером. Суть MOSIX-технологии - способность множества рабочих станций и серверов (узлов) к совместной работе в качестве единой системы (рис. 1). ![]() Рис. 1 MOSIX-кластер Алгоритмы MOSIX ориентированы на контроль над изменением использования ресурсов узлами при преимущественной и прозрачной миграции процессов с одного узла на другой, используют механизмы балансировки нагрузки (load-balancing) и препятствующие уменьшению свободной памяти (memory ushering) на любом из узлов. MOSIX - масштабируемая технология, которая является попыткой улучшения общей производительности при динамическом распределении и перераспределении рабочей нагрузки и ресурсов между узлами вычислительного кластера любого размера. MOSIX легко поддерживает многопользовательский режим распределения вычислительного времени для запуска как последовательных, так и параллельных задач. C 1982 года технология MOSIX, впервые реализованная для PDP-11, претерпела семь редакций и на данный момент имеет работоспособные версии для UNIX и BSD. В 1999 году перенесена под Linux. Здесь рассматривается седьмая версия данной технологии для ОС Linux. |
Технология MOSIX :: Введение |
Целью данной главы является описание основных принципов MOSIX-технологии для CC (Cluster Computing - кластерные вычисления). MOSIX реализует адаптивный алгоритм распределения ресурсов при эффективном масштабировании в CC любого размера, при наличии распределяемых сетевых ресурсов. Сутью MOSIX-технологии, как уже упоминалось выше, является свойство большого числа узлов (рабочих станций и серверов, включая SMP-системы) работать совместно как единое целое.Целью данной главы является описание основных принципов MOSIX-технологии для CC (Cluster Computing - кластерные вычисления). MOSIX реализует адаптивный алгоритм распределения ресурсов при эффективном масштабировании в CC любого размера, при наличии распределяемых сетевых ресурсов. Сутью MOSIX-технологии, как уже упоминалось выше, является свойство большого числа узлов (рабочих станций и серверов, включая SMP-системы) работать совместно как единое целое. Для понимания сути MOSIX-технологии, сравним разделяемую память в SMP-системах и CC. В SMP-системах несколько процессоров совместно используют память. Основное преимущество данных систем заключается в увеличенном объеме обработки данных и быстрой коммуникации между процессами (посредством разделяемой памяти). SMP-системы могут оперировать множеством одновременно запущенных процессов с эффективным распределением и разделением ресурсов. В любой момент времени процесс может быть запущен, завершен или изменен его вычислительный профиль, причём система немедленно адаптируется к новой среде выполнения (среда выполнения - совокупность процессов, запущенных в системе). Пользователь данным процессом не управляет и в большинстве случаев даже не знает о изменениях в среде выполнения, не говоря уже о тех действиях, которые выполняет ОС при запуске нового процесса в SMP-системе. В отличие от SMP, CC является совокупностью рабочих станций и серверов (т.е. узлов), с различными скоростями процессоров и размерами оперативной памяти, возможно разных поколений. Зачастую СС проектируются для многопользовательского, разделяемого во времени процесса вычислений. В СС-системах пользователь несёт ответственность за распределение процессов на узлах и управление ресурсами кластера (кластеры типа Beowulf). В большинстве СС, даже если все узлы находятся под управлением одной ОС, взаимодействие между узлами до некоторой степени ограниченны, потому что большинство сервисов ОС запущены на каждом узле. Основные пакеты СПО для распределения процессов в СС, такие как PVM и MPI, LSF и Extreme Linux обеспечивают аналогичный подход. Эти пакеты предусматривают среду выполнения, требующую адаптированных приложений и осведомленность пользователя об этом. Они включают в себя утилиты для инициализации (фиксации) привязки процесса к узлу, который иногда использует загрузку по соображениям, игнорируя доступные ресурсы, например, свободная память и процессы ввода-вывода. Эти пакеты запускаются на уровне пользователя, правда, только как обычные приложения, таким образом, становятся неспособными реагировать на неустойчивую загрузку или другие ресурсы или адаптивно перераспределять рабочую нагрузку. На практике, проблемы распределения ресурсов более сложные, потому что использование большинства ресурсов, таких как CPU, оперативная память, I/O, IPC и т.д., непрогнозируемо. Сложность получения правильных результатов следует и из факта, что различные пользователи не координируют свою активную деятельность. Допустим, что оптимизация распределения ресурсов между процессами достигнута, но активность другого пользователя может помешать установившейся оптимизации. Для пользователя SMP-система гарантируется эффективное и сбалансированное использование ресурсов между всеми запущенными процессами, несмотря на запросы. SMP-системы просты в использовании по причине того, что они применяют адаптивное управление ресурсами, которое, к тому же, полностью прозрачно для пользователя. Существующие CC не обладают данным свойством. Они полагаются на контролируемое пользователем однозначное распределение, которое неудобно и может вводить значительное снижение производительности системы, вводя её при этом в дисбаланс. Основа технологии MOSIX - алгоритм, поддерживающий адаптивное распределение ресурсов в масштабируемых СС с динамической миграцией процессов. Это можно увидеть специальными средствами СПО СС при закрытии среды выполнения SMP-системы. По возможности размещение ресурсов происходит глобально, распределение рабочей нагрузки динамически и эффективно. Данный подход упрощенно используется в СС при снятии пользователем запросов на ресурсы кластера. Это наглядным образом представлено в многопользовательских, разделяемых во времени средах и неординарных СС. |
Технология MOSIX :: Что такое MOSIX |
MOSIX - СПО для ядер UNIX-like ОС, таких как Linux, состоящее из адаптивных алгоритмов разделения ресурсов. Это позволяет множеству однопроцессорных (UP - Uni-Processors) и SMP узлам запускаться для работы в замкнутой кооперации. Алгоритмы разделения ресурсов MOSIX разработаны в соответствии с использованием ресурсов узлов в режиме реального времени. Это достигается миграцией процессов с одного узла на другой, преимущественно и прозрачно, для балансировки загрузки (load-balancing) и предотвращения истощения памяти. Целью - увеличение суммарной производительности и создание удобной многопользовательской и разделяемой по времени среды для запуска последовательных и параллельных приложений. Стандартное время выполнения среды MOSIX представляет собой СС, в котором глобальные ресурсы кластера доступны каждому узлу. При запрещении автоматической миграции процессов, пользователь может переключить конфигурацию в простой СС или другой single user MPP режим (single user Massively Parallel Processing - обработка данных с массовым параллелизмом в однопользовательском режиме). Текущая реализация MOSIX разработана для СС на основе рабочих станций X86/Pentium, обоих типов (UP и SMP), соединённых стандартной ЛВС. Возможна конфигурация, основывающаяся на маленьких кластерах с РС, соединенными Ethernet, либо на основе производительных систем с большим числом узлов на основе high-end Pentium SMP серверов соединенных посредством Gigabit LAN, например, Myrinet. |
Технология MOSIX :: Что такое MOSIX :: Изнутри |
Технология MOSIX состоит из двух составляющих: механизма PPM и набора алгоритмов для адаптивного разделения ресурсов. Обе составляющие реализуются на уровне ядра, используя загружаемые модули, не модифицирующие интерфейс ядра, таким образом, оставаясь полностью прозрачным для уровня приложений, тем более для уровня пользователя. PMM может мигрировать любой процесс, в любое время, на любой доступный узел кластера. Обычно, миграция основывается на информации предоставляемой одним из алгоритмов разделения ресурсов, но пользователи могут аннулировать любой автоматический выбор системы миграции своего процесса и выполнит то же самое при ручном управлении. Также ручная миграция может инициироваться процессом синхронно, или по явному запросу другого процесса любого пользователя (или суперпользователя). Ручная миграция процессов может быть полезна для представления конкретных режимов (policy) или для тестирования различных планирующих алгоритмов (scheduling algorithms). Необходимо также отметить, что суперпользователь имеет дополнительные привилегии относительно РРМ, например, определение установок общей политики и списка доступных узлов кластера для миграции процессов. Каждый процесс имеет UHN, где он был запущен. Обычно это узел на котором пользователь залогинировался (logged-in). В PVM таким узлом является тот, где задача породила процесс при помощи демона PVM. Образная системная модель MOSIX - СС, в котором каждый процесс представляется запущенным на его UHN и все процессы пользовательской сессии разделены в соответствии с условиями выполнения программы на UHN. Процесс, который мигрирует на другой (удалённый) узел, в любом случае использует ресурсы удалённого узла, но взаимодействует с пользовательской средой через UHN. Например, предположим, что пользователь запустил несколько процессов, некоторые из которых мигрируют с UHN. Если пользователь воспользуется утилитой ps, которая сообщает статус всех процессов, включая процессы которые запущены на удалённом узле. Если один из мигрировавших процессов читает текущее время посредством системного вызова gettimeofday(), то он получит текущее значение времени на UHN. РРМ является основным инструментом для алгоритмов управления ресурсами. До тех пор пока запросы на ресурсы, такие как CPU или основная память, ниже некоторого предела, пользовательские процессы находятся на UHN. Когда запросы на ресурсы превышают некоторый изначально установленный уровень, то процесс может мигрировать на другой узел, воспользовавшись доступными удалёнными ресурсами. Итоговой целью является максимизирование производительности посредством рационального использования разделяемых сетевых ресурсов. Детализация работы распределения ресурсов в MOSIX является процессом. Пользователи могут запускать параллельные приложения для инициализации множества процессов на одном узле, затем позволить системе привязать эти процессы лучшему из свободных на тот момент узлов. Если во время запуска процессов требуемые ресурсы невозможно предоставить на UHN, то алгоритмы разделения ресурсов рассчитывают использовать разделяемые сетевые ресурсы, по возможности перераспределяя процессы по узлам. Свойство привязать и перераспределить процессы особенно важно для "простого в использовании" интерфейса и предоставляют эффективную многопользовательскую и разделяемую во времени среду выполнения. MOSIX не имеет центрального управления и отношений master-slave между узлами: каждый узел может оперировать как автономная система и это делает весь контроль независимым. Такое решение позволяет динамическую конфигурацию, когда узлы способны подсоединяться или отключаться от сети с минимальными нарушениями работоспособности. Алгоритмы масштабирования обеспечивают, что система запустится как на большой конфигурации, так и на малой. Масштабирование достигается введением случайности в алгоритмах контроля системы, где каждый узел основывается на выборе частичных знаний о состоянии на других узлах и делает неравномерным попытку определить общее состояние кластера или конкретного узла. Например, в вероятностной информации распространенных алгоритмов, каждый узел посылает через определённые промежутки времени информацию о доступных ресурсах на случайно выбранную группу других узлов. Одновременно это все поддерживает маленькое "окошко" с наиболее свежеполученной информацией. Эта сема поддерживает масштабирование, равномерная информация распространяется и динамически конфигурируется. |
Технология MOSIX :: Что такое MOSIX :: Алгоритмы разделения ресурсов |
Основные алгоритмы разделения ресурсов в MOSIX это распределение нагрузки (load-balancing) и диспетчер памяти (memory ushering). Динамический алгоритм распределения нагрузки непрерывно пытается уменьшить разницу в загрузке между парами узлов миграцией процессов с более загруженного узла на менее нагруженный. Эта схема децентрализована: все узлы запускают одни и те же алгоритмы, и уменьшение загрузки различно нагруженных выполняется независимо от пар узлов. Число процессоров на каждом из узлов и их скорость являются важным фактором для алгоритма распределения нагрузки. Этот алгоритм реагирует на изменение загрузки на узле или на характеристики процессора в реальном режиме времени. Это доминирует до тех пор, пока нет критической нехватки ресурсов, например, свободной памяти или слотов для процессов. Алгоритм предотвращения истощения памяти работает при росте потребления оперативной памяти процессом (процессами), позволяет избежать своппинга. Алгоритм срабатывает, когда узел запускает страницу памяти превышающую наличную свободную память (рис. 2). В этом случае алгоритм подменяет алгоритм распределения нагрузки и пытается мигрировать процесс на узел, на котором имеется в достаточном количестве свободная память, необходимая для миграции, но возможно неравномерная по распределению нагрузки). ![]() Рис.1 Алгоритм предотвращения истощения памяти |
Технология MOSIX :: Миграция процессов |
MOSIX поддерживает полностью прозрачный процесс PPM. После миграции, процесс продолжает взаимодействовать со своей средой выполнения независимо от его положения на узлах кластера. Реализуя РРМ, мигрирующий процесс разделяется на два контекста: контекст пользователя - который мигрирует и контекст системы, зависящий от UHN и не способный к миграции. Контекст пользователя, называемый также удалённый (remote), содержит программный код, стек, данные, карты памяти и регистры процесса. Удалённый контекст инкапсулирует процесс когда он запускается на уровне пользователя. Системный контекст, называемый также заместитель (deputy), содержит описания ресурсов, которые процесс присоединяет к себе и стек ядра для запуска системного кода от имени процесса. Представитель инкапсулирует процесс когда он запускается на уровне ядра. Это сохраняет узло-зависящую часть системного контекста процесса, следовательно это должно остаться на UHN процесса. В то время как процесс мигрирует в течении времени между различными узлами, представитель никогда не мигрирует. Интерфейс взаимодействия между контекстом пользователя и системным контекстом хорошо определен. Поэтому возможен перехват каждого взаимодействия между этими контекстами, что способствует взаимодействию через сеть. Связь реализуется посредством соединительного канала для взаимодействия. На рисунке 3 показано взаимодействие двух процессов которые разделены UNH. На рисунке левый процесс является нормальным процессом ОС Linux в то время как правый процесс разделен и его удалённая часть мигрировала на другой узел. ![]() Рис. 3 Взаимодействие процессов. Удаленный и представитель. Время миграции имеет фиксированный компонент, для порождения нового кадра процесса на новом (удалённом) узле, и линейный компонент, пропорциональный количеству страниц памяти для передачи. Для минимизации издержек на миграцию передаются только страница таблиц и "запорченные" страницы процесса. При выполнении процесса в MOSIX, независимость местоположения выполняемого процесса достигается перераспределением по узлам, зависящим от системных вызовов к заместителю на UHN. Системный вызов синхронизируется взаимодействием между двумя контекстами процессов. Все системные вызовы, запущенные процессом, перехватываются на уровне связи (link layer) удаленного узла. Если системный вызов не зависит от узла, то он выполняется локально на удалённом (на удалённом узле). В противном случае, системный вызов транслируется заместитель, который запускает системный вызов от имени процесса в UHN. Заместитель возвращает результат обратно на удалённый узел, который затем продолжает выполнение пользовательского кода. Иными формами взаимодействия между двумя контекстами процесса являются выдача сигналов (signal delivery) и процессы-сторожа (process wakeup events), например, срабатывающие на прибытие каких-либо данных по сети. Эти события требуют, чтобы заместитель асинхронно размещался и взаимодействовал с удаленным. Такое размещение требует встречного коммуникационного канала между ними. Обычно ядро на UHN информирует заместителя о событии. Заместитель проверяет необходимо ли с его стороны какие-либо действия или нет, если это так и необходимо отреагировать, то заместитель в свою очередь информирует удаленного. Удаленный контролирует канал взаимодействия для сообщений об асинхронных событиях, например, сигналов, только после возобновления выполнения на пользовательском уровне. Этот основной принцип заложен в технологию MOSIX, при этом модификация ядра отсутствует, поэтому возможно беспрепятственное перенесение данной технологии на другие архитектуры. Одним из недостатков принципа заместителя заключается в дополнительных накладных расходах при запуске системных вызовов. Дополнительные затраты следуют из файловых и сетевых операциях доступа. Например, все сетевые связи (сокеты) создаются на UHN, таким образом, налагая накладные расходы связанные с соединением, если процесс мигрирует прочь с UHN. Для компенсации данной проблемы разработана технология "мигрирующих сокетов", которая переносит процесс и позволяет осуществить прямую связь между мигрировавшими процессами. В настоящее время такие издержки могут быть значительно уменьшены при начальном распределении коммуникационных процессов на различные узлы, например, используя PVM/MPI. Если система становится неустойчивой, то алгоритмы MOSIX переназначают процессы для улучшения производительности. |
Технология MOSIX :: Реализация |
Перенос MOSIX под Linux уже реально осуществлен. Также разработан интерактивный отладчик ядра, предпосылкой для любого проекта в данной сфере. Отладчик активизируется или по запрос пользователя, или при сбое ядра. Это позволяет разработчику рассмотреть память ядра, процесса, содержимое стека и т.д. К тому же, существует возможность трассировать системный вызов и процесс изнутри ядра; такое событие вставляет точку останова в код ядра. Основной частью проекта MOSIX для Linux является реализация кода поддержки прозрачности операций разделенного процесса, с контекстом пользователя запущенным на удалённом узле, поддерживающим системный контекст - заместитель, который запущен на UHN. Вместе с тем, реализован коммуникационный уровень, который осуществляет связь между двумя контекстами процесса, а также протокол взаимодействия между ними. Связь между двумя контекстами реализована поверх простого, но исключающего TCP/IP соединения. Далее был реализован механизм миграции процессов, включающий миграцию с UHN, возврат на UHN и миграция между двумя удалёнными узлами, затем модуль обновления информации. Далее, используя эти механизмы, реализуется алгоритм оценки затрат процесса и автоматической миграции его в случае необходимости. В заключении, был разработан и реализован MOSIX API (application programming interface) посредством /proc. Схема MOSIX представлена на рис. 4. ![]() Рис. 4 Структура MOSIX. |
Технология MOSIX :: Реализация :: Механизм представитель/удаленный |
Заместитель представляет удаленного процесса на UHN. В то время как пространство памяти пользователя в целом постоянно находится на удалённом узле, заместитель хранит свою карту памяти. Вместе это разделение основной памяти ядра подобно нитям ядра. В большинстве своем деятельность ядра, такая как запуск системных запросов, представляет собой передачу данных между пространством пользователя и ядра. Такое взаимодействие осуществляется при помощи примитивов ядра copy_to_user(), copy_from_user(). В MOSIX любая операция ядра с памятью включает в себя доступ к пространству пользователя, требующего связи заместителя с удалённым для передачи необходимых данных. Накладные расходы на связь обусловленные операциями удалённого копирования, которые могут повторяться в течение некоторого времени без простого системного вызова, совершенно реальны и представлены, главным образом, задержками передачи по сети. Устранить наиболее часто встречающееся избыточное удаленное копирование, были разработан специальный кеш, уменьшающий число требуемых взаимодействий упреждающей выборкой стольких данных, сколько возможно выбрать в течении инициализации системного запроса, в то время как буферизированная часть данных заместителя возвращается удаленному по окончанию системного вызова. Для предохранения от удаления основных отображаемых в памяти файлов (для страниц по требованию) в отсутствии карты памяти, заместитель хранит специальную таблицу тех файлов, которые отображаются в памяти у удаленного. Регистры пользователя мигрированного процесса нормально находятся в контексте удаленного. Впрочем, каждый регистр или комбинация регистров, может стать временно захвачена для управления заместителем. Удаленный (гостевой процесс) недоступен для других процессов, которые запущены на этом узле (локальных или любых других мигрированных с других узлов) и наоборот. Они не принадлежат любому конкретному пользователю (на удаленном узле, где они работают) и также они не могут послать сигналы или провести любые другие манипуляции с локальным процессом. Их память закрыта для доступа и они могут в принудительном порядке, под контролем системного администратора, мигрировать куда-нибудь еще. Процесс может нуждаться в совершении некоторых MOSIX-функций в то время как логически он спит или остановлен. Так процесс запустивший MOSIX-функции "в совей спячке", прерывает свой сон, если случится какое-нибудь событие, которого он ожидает. Например, процесс мигрировал, возможно в то время когда он спал. С этой целью, MOSIX поддерживает логическое состояние, описывая в каком состоянии другой процесс увидит процесс, в отличии от его непосредственного состояния. |
Технология MOSIX :: Реализация :: Ограничение миграции |
Некоторые функции Linux-ядра не совместимы с таким разделением контекста процесса (заместитель+удаленный). Очевидными примерами могут являться прямые манипуляции с устройствами ввода/вывода, т.е., прямой доступ к привилегированным инструкциям шинного ввода/вывода, или прямой доступ в памяти устройства. Другим примером может являться разделяемая память с перезаписью и выполнение в режиме реального времени. Последнее не позволительно потому, что нет никаких гарантий, что во время миграции не произойдет миграции процессов с других узлов, что может нарушить баланс со всеми вытекающими для процесса реального времени последствиями. Так же по этим же причинам невозможно мигрировать потоки. Процесс, который использует любую из вышеприведенных особенностей автоматически блокируется на своем UHN. Если процесс все же был уже мигрирован, то он в первую очередь возвращается на UHN. |
Технология MOSIX :: Реализация :: Сбор информации |
Статистика о характере поведения процесса собирается постоянно, каждый системный вызов и во время доступа к данным пользователя. Эта информация используется для определения какому процессу необходимо мигрировать с UHN. Данная статистика обновляется со временем, для приведения ее в соответствие с теми изменениями, которые производит процесс меняя свои параметры выполнения. Она также очищается полностью при системном вызове execve(2), то есть с тех пор как процесс вероятно изменил свой характер. Каждый процесс контролирует сбор и обновление статистики. Для привязки, процесс может выполнить стадии ознакомления с характеристиками, подлежащими изменению или он может циклически чередовать комбинации вычисления и вода/вывода. |
Технология MOSIX :: Реализация :: MOSIX API |
MOSIX API традиционно реализуется посредством набора зарезервированных системных вызовов, которые используются для конфигурирования, запросов и операций MOSIX. По соглашению Linux, разработчиками используется API представленный интерфейсом посредством каталога /proc файловой системы. Это также предотвращает возможность двоичной несовместимости программ пользователя между различными версиями Linux. API реализуется как расширение каталога /proc с новой поддиректорией /proc/mosix. Вызовы MOSIX посредством /proc включают:
|
Технология MOSIX :: Заключение |
MOSIX представляет собой новое измерение в масштабируемых кластерных технологиях для Linux. Это позволяет создавать масштабируемые вычислительные кластеры с высокой производительностью из общедоступных компонент, где масштабирование не вносит накладные расходы на вычисления. Основным достоинством MOSIX по сравнению с другими CC заключается в способности отвечать на непредсказуемые и беспорядочные требования пользователей на системные ресурсы. Наиболее значительное свойство запуска программ на MOSIX заключается в адаптации ресурсов к политике распределения, симметричность и гибкость конфигурации. Комбинированный эффект вышеприведенных свойств означает, что пользователи не должны знать текущее состояние использования ресурсов на различных узлах, или их число. Параллельные приложения может быть запущено с позволения MOSIX на лучшем из возможных узлов, в большинстве случаем на SMP. MOSIX R&D-проекты включают в себя несколько направлений. Это и мигрирующие сокеты, которые способны уменьшить накладные расходы при IPC. Это и мигрирующие временные файлы, которые может использовать удаленный процесса, например, компилятор, создающий временный файл на удаленном узле. Основной концепцией такой оптимизации является увеличение числа ресурсов, мигрирующих с процессом, для уменьшения удаленных издержек по доступу. Другим проектом, который разрабатывается на базе MOSIX, является новым алгоритмом адаптационного управления ресурсами, который может идентифицировать большое количество различных ресурсов, таких как память, процессор, IPC и ввод/вывод. Так же исследуются алгоритмы сетевой памяти (network RAM), в которой большие процессы используют всю доступную память на различных узлах кластера. Идея рассредоточения данных процесса между большим количеством узлов, и правильнее мигрировать (обычно маленький) процесс с данными, которые доставляются процессу. В будущем, планируется расширить список поддерживаемых MOSIX платформ, таких как DEC Alpha и SUN Sparc. |
MOSIX-кластер в СПбГТУ |
Аппаратная часть кластера представляется нижеприведенной конфигурацией. Узел 1
Узел 2
Узел 3
Среда передачи кластера основывалась на технологии 10BASE-T. В качестве узла коммутации был использован концентратор 3Com SuperStack II 24X10Mbit port Программная часть кластера представляется нижеприведенной конфигурацией (конфигурация для всех узлов одинаковая):
|
MOSIX-кластер в СПбГТУ :: Тестирование производительности |
Тестирование кластера производилось в два этапа с помощью написанного программного обеспечения: Этап первый. Тестирование кластера идеально распараллеливающимся программным обеспечением. Этап второй. Тестирование кластера программным обеспечением использующим реальные механизмы межпроцессного взаимодействия:
Полученные в ходе эксперимента результаты отразим в виде графических зависимостей и диаграмм. |
MOSIX-кластер в СПбГТУ :: Идеальные условия |
Идеализированные условия представляются специально написанной программой, которая написана таким образом, что минимизирует всякое взаимодействие между процессами, порождая 12 потомков с одинаковой вычислительной нагрузкой. В априори можно утверждать, что производительность должна стремиться в максимальной, т.е. 300% (для трех узлов), что подтверждается результатами экспериметов Результаты эксперимента таковы, что:
|
MOSIX-кластер в СПбГТУ :: Реальные условия |
Для тестирования кластера в реальных условиях были написаны три различных класса программ, использующих различные IPC. Каждый класс подзадач подразумевает под собой проведение трех разных экспериментов с разной интенсивностью обмена между процессами: минимальной, средней и максимальной. Но в силу определенной специфики, тестирование на максимальной интенсивности не производилось ввиду большой длительности данных испытаний и нецелесообразности данного подхода, т.к. программы с большой интенсивностью взаимодействия можно считать 100% не параллельными. Вместо этого использовалась интенсивность близкая к максимальной.
|
MOSIX-кластер в СПбГТУ :: Реальные условия :: Неименованные каналы |
Минимальная интенсивность обмена:
Средняя интенсивность обмена:
Максимальная интенсивность обмена:
|
MOSIX-кластер в СПбГТУ :: Реальные условия :: Именованные каналы |
Минимальная интенсивность обмена:
Средняя интенсивность обмена:
Максимальная интенсивность обмена:
|
MOSIX-кластер в СПбГТУ :: Реальные условия :: Очереди сообщений |
Минимальная интенсивность обмена:
Средняя интенсивность обмена:
Максимальная интенсивность обмена:
|
MOSIX-кластер в ИВЦ СамГТУ :: Результаты |
Для полноты картины следует сослаться на результаты, полученные при тестировании трехузлового кластера в ИВЦ СамГТУ (г. Самара, Россия). При перемножении матрицы 1600 на 1600 была получена 170% производительность из 300% возможных. Таким образом, производительность очень сильно зависит от характера IPC, поэтому производительность кластера на задачах является основным критерием при делении программ на параллельные и программы с совпадающими участками кода. |
MOSIX-кластер в СПбГТУ :: Анализ результатов |
|