Реферат: Менеджер управления распределенными вычислениями в локальной сети

4. Простота контроля загруженности канала сэмплирования (наряду со стандартными метриками каналов введены счетчики посланных и принятых запросов в диспетчере, в заголовок запроса включено поле – время отправления, по которому при возвращении запроса определяется время его осуществления);

5. Контроль потока служебной информации (легко регулируется периодичность запросов);

6. Простота сбора данных.

В каждом запросе указывается объект определенной иерархии и запрашиваемая метрика:

· вид ресурсов;

· уровень иерархии;

· номер объекта на данном уровне иерархии;

· код запрашиваемой метрики для данного объекта.

Структура получаемой информации однозначно определяется типом объектов указанных в запросе.

Возможно получение информации сразу по всем объектам и/или всем метрикам – при указании специальных значений последних двух полей. В данном случае в ответ на запрос возвращается массив однотипных структур.

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

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

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

Для задач вычисляются общее время вычисления, время обмена данными и др.

Для каналов: счетчики входов в процедуры обмена send/recv , объем переданных/принятых данных, среднее время нахождения в режиме приема/передачи и др.

5. Контроль производительности.

В данном разделе описываются идейные соображения для построения системы, анализирующей производительность параллельных программ в реальном времени.

Накопленная диспетчером информация – рабочий профиль – может использоваться для анализа выполнения параллельной программы. Далее описан примерный сценарий анализа.

Пусть задан вопрос: работает ли программа эффективно .

Гипотеза H₀ : программа работает эффективно.

Гипотеза H₁ : программа работает неэффективно.

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

· большая доля времени простоя задач от общего времени работы.

Упрощенно это выражается следующим выражением:

Можно взять критерий: E _п < 0,8.

Итак, если время простоя занимает более 20 процентов общего времени работы программы, то есть основания считать работу программы неэффективной.

Подтвердив данную гипотезу – первого уровня, – переходим к анализу гипотез второго уровня. Предположим, в программе имеется «узкое место» в плане обмена данных. Рассмотрим участок графа потоков данных программы, показанный на рисунке.

Взаимодействуют две задачи через канал. Задача T₁ генерирует данные, они передаются по каналу, являющемуся выходным для T₁ , а задача T₂ принимает их на свой входной порт и обрабатывает.