Документация Erlang / SMP: одноузловая и многоузловая для каждого компьютера или приложения, а также возможная путаница - PullRequest
2 голосов
/ 07 декабря 2009

Я сейчас изучаю модель процесса Эрланга. Я наткнулся на загадку в техническом отчете (раздел 3, параграф 2) на Erlang:

Это объясняет, почему в некоторых случаях может быть более эффективно запускать несколько SMP VM с одним планировщиком каждый вместо этого на одной SMP VM с несколькими планировщиками . Конечно запуск нескольких виртуальных машин требует, чтобы приложение могло выполняться во многих параллельных задачах который не имеет или очень мало общается друг с другом.

Теперь этот параграф сбивает меня с толку; Я вижу сценарий однопроцессного множественного планировщика, но мне не удается увидеть несколько процессов с одним планировщиком; Предположительно, каждый процесс будет иметь другое имя узла , и это будет означать, что определенное приложение без модификации не может использоваться с этой моделью; достоинство не требующего модификации было упомянуто в качестве ключевой особенности SMP в отчете. Если несколько процессов имеют одинаковые имена узлов, производительность может быть катастрофической из-за штормов обмена сообщениями между процессами Эрланга - это предполагает использование амнезии в памяти . Есть ли какая-то модель процесса, которая не представлена ​​в статье и которой мне здесь не хватает?

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

- редактировать 1: Разъяснение источника проблемы -

На вопрос был дан ответ путем обсуждения; ниже приводится описание проблемы, с которой я столкнулся.

Проблема этого вопроса заключалась в том, что документация, насколько я помню, не касается сценария запуска нескольких эмуляторов Эрланга на физическую машину - всегда было показано, что эмулятор представляет вашу физическую машину (в промышленном использовании ); Кроме того, сценарий необходимости явного разделения программы для вычислительной эффективности никогда не рассматривался. Это внезапное знакомство стало источником моего горя.

Соглашение по-прежнему смещено в сторону создания МНОЖЕСТВА процессов и что в будущем будет много улучшений для эмулятора SMP для Erlang, и это означает, что один узел на машину по-прежнему остается весьма жизнеспособным вариантом, предполагающим благоприятный дизайн приложения.

Ответы [ 4 ]

5 голосов
/ 07 декабря 2009

Переписать после прочтения статьи:

Это объясняет, почему в некоторых случаях это может быть более эффективным для запуска нескольких SMP ВМ с одним планировщиком каждый вместо на одной SMP VM с несколькими планировщиками.

  • Виртуальная машина без SMP не имеет блокировки, поэтому работает быстро.
  • Один планировщик SMP VM на 10% медленнее из-за затрат на проверку блокировок
  • SMP VM с несколькими планировщиками снова работает медленнее из-за использования / ожидания блокировок

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

  • Я думаю : Узлы на одном и том же сервере должны иметь разные имена.
  • Межпроцессный обмен сообщениями происходит медленнее из-за межпроцессного характера стихов внутрипроцессного обмена сообщениями узла ВМ.
2 голосов
/ 08 декабря 2009

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

Возьмем, к примеру, четырехъядерный компьютер. Вариант 1 означает, что вы запускаете четыре экземпляра виртуальной машины Erlang, каждый с одним планировщиком, а привязка устанавливается к разным ядрам процессора. Второй вариант означает запуск одной виртуальной машины Erlang с четырьмя планировщиками, причем привязка каждого планировщика настроена на разные ядра процессора.

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

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

1 голос
/ 09 декабря 2009

Есть несколько адвантангов с несколькими узлами на одной физической машине.

1) Затраты ресурсов на блокировку, как уже упоминалось.

2) Отказ. В телекоммуникационных продуктах вы действительно не хотите, чтобы луч рухнул на вас. Если в вашей системе есть NIF или встроенные драйверы, это может произойти.

3) Память местности. Несколько узлов - это простой способ форсировать процессы несколькими ядрами. Это может быть большим подспорьем для арок NUMA, но также и для SMP. Планировщик не учитывает NUMA (пока). Вы можете запустить процесс в определенном планировщике и заблокировать его, он не будет мигрировать, но это недокументированная функция ... или он был удален все вместе. Я забыл.

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

Однако числа из документов EUC старше года [@], и я бы не рекомендовал многоузловой подход, если он вам действительно не нужен. Система времени выполнения гораздо лучше справляется с такими проблемами сегодня. Многие накладные расходы были удалены, а mrq-планировщик был улучшен.

Числа

@ 2009 выглядят как это .

Edit:

Относительно 3) упомянутой мной функции появления,

spawn_opt(fun() -> ... end, [{scheduler, Id}]) -> pid(),
    where Id is an integer and refers to a specific scheduler.

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

1 голос
/ 07 декабря 2009

Я считаю, что ответ в предыдущем абзаце:

SMP VM только с одним планировщиком немного медленнее (10%), чем не СМП ВМ. Это потому, что SMP VM должен использовать блокировки для всех общих datastructures. Но, как До тех пор, пока нет конфликтов блокировки, накладные расходы, вызванные блокировка не так высока (это конфликты блокировок, которые требуют времени).

Зависимость планировщика от блокировок для общих структур данных может привести к накладным расходам в данной системе. Из этого следует, что наличие нескольких планировщиков на одной виртуальной машине SMP влечет за собой все большие издержки.

...