Документация Erlang/SMP: одноузловая и многоузловая на машину или на приложение, а также замешательство, которое может следовать

Question

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

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

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

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

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

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

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

Соглашение по-прежнему предвзято направлено на создание LOTS процессов и что будущее содержит много улучшений для эмулятора SMP для Erlang, а это означает, что один узел на машину по-прежнему является очень жизнеспособным вариантом, предполагающим благоприятный дизайн приложения.

Answer 1

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

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

• Non-SMP VM не имеет замок так быстро бегает.
• Single планировщик SMP VM 10% медленнее, из-за стоимости проверки замков
• Multiple планировщик SMP VM медленнее снова из-за использование/ожидание блокировки

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

• Я думаю: Узлы на одном сервере должны иметь разные имена.
• Обмен сообщениями между процессами, в то время как медленнее из-за взаимодействия между процессами внутри процесса обмена сообщениями узла VM.

Answer 2

Я считаю, что ответ находится в предыдущем пункте:

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

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

Answer 3

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

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

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

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

Answer 4

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

1) Накладные расходы на ресурсы, как указано.

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

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

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

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

@ номера 2009 года выглядят как this.

Edit:

Что касается 3) порождение черта я упомянул есть

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

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