Ваши ответы здесь: https://hamidreza -s.github.io / erlang / планирование / в режиме реального времени / упреждающий / миграция / 2016/02/09 / erlang-scheduler-details.html
Повторное размещение здесь, позволяющее редактировать.
Erlang Scheduling
Erlang в качестве платформы реального времени для многозадачности использует Preemptive Scheduling.Ответственность планировщика Erlang заключается в выборе процесса и выполнении его кода.Он также занимается сборкой мусора и управлением памятью.Фактор выбора процесса для выполнения основан на их уровне приоритета, который настраивается для каждого процесса, и на каждом уровне приоритета процессы планируются в циклическом режиме.С другой стороны, фактор исключения процесса из процесса основан на определенном количестве сокращений с момента последнего выбора его для выполнения, независимо от его уровня приоритета.Сокращение - это счетчик на процесс, который обычно увеличивается на единицу для каждого вызова функции.Он используется для прерывания процессов и переключения их контекста, когда счетчик процесса достигает максимального числа сокращений.Например, в Erlang / OTP R12B это максимальное число составляло 2000 сокращений.
Планирование задач в Erlang имеет долгую историю.Это менялось с течением времени.На эти изменения повлияли изменения в функции SMP (симметричная многопроцессорная обработка) Erlang.
Планирование до R11B
До R11B Эрланг не имел поддержки SMP, поэтомув потоке основного процесса ОС был запущен только один планировщик и, соответственно, существовала только одна очередь выполнения.Планировщик выбрал выполняемые процессы Erlang и задачи ввода-вывода из очереди выполнения и выполнил их.
Erlang VM
+--------------------------------------------------------+
| |
| +-----------------+ +-----------------+ |
| | | | | |
| | Scheduler +--------------> Task # 1 | |
| | | | | |
| +-----------------+ | Task # 2 | |
| | | |
| | Task # 3 | |
| | | |
| | Task # 4 | |
| | | |
| | Task # N | |
| | | |
| +-----------------+ |
| | | |
| | Run Queue | |
| | | |
| +-----------------+ |
| |
+--------------------------------------------------------+
Таким образом, не было необходимости блокировать структуры данных, но написанное приложение не могло использовать преимущества параллелизма.
Планирование в R11B и R12B
В виртуальную машину Erlang была добавлена поддержка SMP, поэтому в каждый поток ОС могло быть включено от 1 до 1024 планировщиков.Однако в этой версии планировщики могут выбирать выполняемые задачи только из одной общей очереди выполнения.
Erlang VM
+--------------------------------------------------------+
| |
| +-----------------+ +-----------------+ |
| | | | | |
| | Scheduler # 1 +--------------> Task # 1 | |
| | | +---------> | |
| +-----------------+ | +----> Task # 2 | |
| | | | | |
| +-----------------+ | | | Task # 3 | |
| | | | | | | |
| | Scheduler # 2 +----+ | | Task # 4 | |
| | | | | | |
| +-----------------+ | | Task # N | |
| | | | |
| +-----------------+ | +-----------------+ |
| | | | | | |
| | Scheduler # N +---------+ | Run Queue | |
| | | | | |
| +-----------------+ +-----------------+ |
| |
+--------------------------------------------------------+
Из-за результирующего параллелизма этого метода все общие структуры данных защищены блокировками.Например, сама очередь выполнения является общей структурой данных, которая должна быть защищена.Хотя блокировка может обеспечить снижение производительности, улучшения производительности, которые были достигнуты в системах с многоядерными процессорами, были интересны.
Некоторые известные узкие места в этой версии были следующими:
Общая очередь выполнения становитсяузкое место, когда количество планировщиков увеличивается.Увеличение вовлеченной блокировки таблиц ETS, которая также влияет на Mnesia.Усиление конфликтов блокировки, когда многие процессы отправляют сообщения одному и тому же процессу.Процесс, ожидающий блокировки, может заблокировать свой планировщик.Однако для решения этих проблем узкого места в следующих версиях было выбрано разделение очередей выполнения для каждого планировщика.
Планирование после R13B
В этой версии у каждого планировщика есть собственная очередь выполнения.Это уменьшает количество конфликтов блокировок в системах со многими планировщиками на многих ядрах, а также повышает общую производительность.
Erlang VM
+--------------------------------------------------------+
| |
| +-----------------+-----------------+ |
| | | | |
| | Scheduler # 1 | Run Queue # 1 <--+ |
| | | | | |
| +-----------------+-----------------+ | |
| | |
| +-----------------+-----------------+ | |
| | | | | |
| | Scheduler # 2 | Run Queue # 2 <----> Migration |
| | | | | Logic |
| +-----------------+-----------------+ | |
| | |
| +-----------------+-----------------+ | |
| | | | | |
| | Scheduler # N | Run Queue # N <--+ |
| | | | |
| +-----------------+-----------------+ |
| |
+--------------------------------------------------------+
Таким образом, конфликты блокировок при доступе к очереди выполнения решаются, но вносит некоторые новые проблемы:
Насколько честен процесс разделения задач между очередями выполнения?Что если один планировщик перегружен задачами, в то время как другие бездействуют?На основании какого порядка планировщик может украсть задачи из перегруженного планировщика?Что если мы запустим много планировщиков, но там так мало задач?Эти проблемы побуждают команду Erlang представить концепцию, которая делает планирование справедливым и эффективным, Migration Logic.Он пытается контролировать и балансировать очереди на основе статистики, получаемой из системы.
Однако мы не должны зависеть от того, чтобы расписание оставалось точно таким, как оно есть сегодня, потому что оно, вероятно, будет изменено в будущих выпусках, чтобы стать лучше.
В заключение, есть два вопроса:1. Я хочу подтвердить, существует ли проблема повторной очереди в мире асинхронного программирования.2. Кроме того, действительно ли у Эрланга есть проблема, если он обрабатывает десятки тысяч процессов, особенно если использовать много GenServer.call в цепочке запрос-ответ?
В зависимостио какой версии Erlang вы говорите, есть разные компромиссы.Поскольку в более новых версиях Erlang имеется несколько очередей, ваша проблема не существует в указанной вами форме.
Я видел, что Erlang (и его виртуальная машина) отлично справляются с миллионами процессов Erlang, также использовал систему на основе Erlang для обработки более 100 000 клиентов с очень узким SLA на задержке.Не уверен в деталях вашей проблемы, но разумно написанный сервис Erlang / Elixir может справиться с заданной вами рабочей нагрузкой, если только вы что-то не заметили.