Расстановка приоритетов узлов Erlang - PullRequest
2 голосов
/ 20 мая 2009

Предполагая, что у меня есть кластер из n Erlang узлов, некоторые из которых могут быть в моей локальной сети, в то время как другие могут быть подключены с помощью WAN (то есть через Интернет), какие механизмы являются подходящими для обслуживают: а) различную доступность / поведение полосы пропускания (например, вызванную задержку) и б) узлы с различной вычислительной мощностью (или даже ограничениями памяти)?

Другими словами, как мне назначить приоритеты локальным узлам, обладающим большой вычислительной мощностью, по сравнению с теми, которые имеют большую задержку и могут быть менее мощными, или как бы я идеально расставил приоритеты для высокопроизводительных удаленных узлов с высокими задержками передачи, чтобы конкретно те процессы с относительно большим соотношением вычислений / передачи (то есть выполненной работы на сообщение, в единицу времени)?

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

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

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

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

Ответы [ 2 ]

1 голос
/ 17 июня 2009

Мы сделали что-то похожее на это только на нашей внутренней LAN / WAN (WAN, например, от Сан-Франциско до Лондона). Проблема сводилась к сочетанию этих факторов:

  1. Затраты на простое выполнение удаленного вызова через локальный (внутренний) вызов
  2. Сетевая задержка для узла (как функция полезной нагрузки запроса / результата)
  3. Производительность удаленного узла
  4. вычислительная мощность, необходимая для выполнения функции
  5. Обеспечивает ли пакетирование вызовов какое-либо улучшение производительности, если существует общий «статический» набор данных.

Для 1. мы предполагали отсутствие накладных расходов (оно было незначительным по сравнению с другими)

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

Для 3. мы измерили ее на узле и передали эту информацию (она изменялась в зависимости от тока нагрузки, активного на узле)

Для 4 и 5. мы разработали его опытным путем для данной партии

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

Мы получили намного лучшее использование нашей расчетной "сетки", используя эту технику, но это было довольно немного усилий. У нас было дополнительное преимущество в том, что сетка использовалась только этой средой, поэтому у нас было намного больше контроля. Добавление в интернет-микс (с переменной задержкой) и других пользователей сетки (с переменной производительностью) только увеличит сложность с возможным уменьшением прибыли ...

1 голос
/ 22 мая 2009

Проблема, о которой вы говорите, решалась различными способами в контексте Grid-вычислений (например, см. Condor ). Чтобы обсудить это более подробно, я думаю, что требуется некоторая дополнительная информация (однородность проблем, которые нужно решить, степень контроля над узлами [т.е. есть ли неожиданная внешняя нагрузка и т. Д.?]).

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

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

...