Проект Templet

акторный фреймворк для запуска задач
на множестве ядер, кластерах и в облаках
templet.ssau.ru

Инструменты пользователя

Инструменты сайта


translate:evaluation_of_a_workflow_scheduler_using_integrated_performance_modelling_and_batch_queue_wait_time_prediction

Различия

Показаны различия между двумя версиями страницы.

Ссылка на это сравнение

Предыдущая версия справа и слеваПредыдущая версия
Следующая версия
Предыдущая версия
Следующая версияСледующая версия справа и слева
translate:evaluation_of_a_workflow_scheduler_using_integrated_performance_modelling_and_batch_queue_wait_time_prediction [2013/12/03 20:44] – [Результаты] artamonovtranslate:evaluation_of_a_workflow_scheduler_using_integrated_performance_modelling_and_batch_queue_wait_time_prediction [2013/12/03 21:12] – [Результаты] artamonov
Строка 129: Строка 129:
  
 Хотя мы считаем, что снижение наблюдаемой длительности в основном связано с тем, что мы в состоянии решить, где разместить задачи, на основе моделей производительности ресурсов и времени ожидания задач в очереди, есть другие основания для этих улучшений. Один из таких интересных результатов эксперимента показан в таблице 1, который показщывает среднее количество узлов и систем взаимодействующих с планировщиками БМПОПС и планировщиками без БПМОПС. Из этой таблицы мы можем видеть, что при использовании планировщика с БМПОПС, план использует в среднем меньше уникальных узлов во время фазы выполнения. Хотя мы ожидали, что это будет происходить иногда, мы были удивлены тем, что во многих экспериментах планировщик с БМПОПС использует намного меньше уникальных ресурсов, который интуитивно даёт меньшее общее время ожидания в очереди. В случаях, когда план использует меньше узлов для исполнения залачи, планировщик решил, что это более эффективно - запускать некоторые задачи последовательно на одном узле, чем если бы задачи выполнялись параллельно на нескольких машинах и давать большее время ожидания. Без предсказания времени ожидания, такое решение не будет принято, если модели производительности для одной архитектуры ресурсов предсказывают намного большее время исполнения задач, которого не было в случае нашего довольно однородного набора машин. Хотя мы считаем, что снижение наблюдаемой длительности в основном связано с тем, что мы в состоянии решить, где разместить задачи, на основе моделей производительности ресурсов и времени ожидания задач в очереди, есть другие основания для этих улучшений. Один из таких интересных результатов эксперимента показан в таблице 1, который показщывает среднее количество узлов и систем взаимодействующих с планировщиками БМПОПС и планировщиками без БПМОПС. Из этой таблицы мы можем видеть, что при использовании планировщика с БМПОПС, план использует в среднем меньше уникальных узлов во время фазы выполнения. Хотя мы ожидали, что это будет происходить иногда, мы были удивлены тем, что во многих экспериментах планировщик с БМПОПС использует намного меньше уникальных ресурсов, который интуитивно даёт меньшее общее время ожидания в очереди. В случаях, когда план использует меньше узлов для исполнения залачи, планировщик решил, что это более эффективно - запускать некоторые задачи последовательно на одном узле, чем если бы задачи выполнялись параллельно на нескольких машинах и давать большее время ожидания. Без предсказания времени ожидания, такое решение не будет принято, если модели производительности для одной архитектуры ресурсов предсказывают намного большее время исполнения задач, которого не было в случае нашего довольно однородного набора машин.
 +
 +Из первого эксперимента, кажется решение помощью предсказания очереди пакетной системы, где лучше всего запускать задачи рабочего процесса, помогает сократить наблюдаемое время. Тем не менее, мы понимаем, что в реальных условиях существуют потенциальные скрытые факторы, не связанные непосредственно с временем ожидания в очереди, которые могут повлиять на наши относительно небольшие длительности. Например, загруженный головной узле может затратить ещё несколько секунд, чтобы завершить процесс постановки в очередь, чем на незагруженном головном узле, и так как мы вносим где-то между 90 и 100 работами за испытание, эти секунды могут быть потенциально добавлены к общей длительности эксперимента. По этой причине мы попытались выполнить более реальное исполнение приложений для того, чтобы показать, что разница в самом деле в нашей способности выбирать ресурсы, которые могут стать доступны раньше, чем когда мы игнорируем время ожидания в очереди. В течение одной недели, мы хотели собрать достаточно БМПОПС и не-БМПОПС измерений, чтобы показать подобный график и проанализировать как в нашем первом эксперименте. Результат экспериментального процесса несколько удивил нас, к сожалению, ни один из не-БМПОПС планировщиков не смог даже завершиться из-за различных запланированных простоев и аварий в течение экспериментального периода. Напомним, что мы запускаем наши эксперименты сначала с планировщиком БМПОПС, затем без и повторяем. Во время нашего недельного периода, мы сначала выполняем БПМОПС планирование, который который занимает примерно полдня (45384 секунды). Эксперимент без БМПОПС начался сразу после этого, но после двух дней - эксперимент не завершён, а одна из систем пострадала при неожиданном отключении питания. Когда машина вернулась в строй, мы снова начали эксперимент с планировщиком БМПОПС, который снова занял примерно полдня (49153 секунды). Снова планировщик без БМПОПС начал выполнение, где-то между 1.5 и 2-мя днями спустя, другая система отключила свои узлы из-за перегрева машинного зала, что оставило эксперимент без завершения.
 ==== Заключение ==== ==== Заключение ====
  
translate/evaluation_of_a_workflow_scheduler_using_integrated_performance_modelling_and_batch_queue_wait_time_prediction.txt · Последнее изменение: 2014/03/30 19:45 — artamonov