virtual-machine - BEAM(Erlang VM)은 어떤 종류의 가상 머신입니까?




(4)

Erlang VM은 하나의 OS 프로세스로 실행됩니다. 기본적으로 코어 당 하나의 OS 스레드를 실행하여 시스템을 최대로 활용합니다. VM이 시작될 때 스레드의 수와 코어가 실행되는 코어 수를 설정할 수 있습니다.

Erlang 프로세스는 Erlang VM에 의해 전적으로 구현 되며 OS 프로세스 또는 OS 스레드에 연결되지 않습니다. 따라서 비록 백만 개가 넘는 Erlang 시스템을 운영 중이더라도 여전히 OS 당 하나의 프로세스이고 코어 당 하나의 스레드입니다. 이런 의미에서 Erlang VM은 "프로세스 가상 머신"이고 Erlang 시스템 자체는 OS처럼 동작하며 Erlang 프로세스는 OS 프로세스와 매우 유사한 속성을 가지고 있습니다 (예 : 격리). 실제로 BEAM을 기반으로하는 Erlang VM이 있습니다. BEAM은 베어 메탈에서 실행되며 사실 OS 자체 는 Xen의 Erlang을 참조하십시오.

그런데 수백만 개의 Erlang 프로세스를 실행하는 시스템을 만드는 것이 가능하며 실제로는 WhatsApp 와 같은 일부 제품에서 수행됩니다.

우리는 Erlang의 기본 환경을 설계 할 때 OSes에 대해 확실히 생각하고있었습니다.

가상 컴퓨터가 "시스템 가상 컴퓨터"또는 "프로세스 가상 컴퓨터"의 두 범주로 분류된다는 것을 알고 있습니다. BEAM이있는 곳은 나에게 너무 희미합니다. 다른 종류의 가상 컴퓨터가 있습니까?


가상 머신은 컴퓨팅 시스템입니다. 컴퓨팅 시스템의 궁극적 인 목표는 프로그래밍 된 논리를 실행하는 것입니다. 이러한 관점에서 볼 때 가상 시스템은 추상화 수준 및 에뮬레이션 범위에 따라 4 가지 유형 으로 분류 할 수 있습니다.

유형 1 : ISA (Full Instruction Set Architecture) 가상 시스템 은 전체 컴퓨터 시스템의 ISA 에뮬레이션 또는 가상화를 제공합니다. 게스트 운영 체제 및 응용 프로그램은 실제 컴퓨터 (예 : VirtualBox, QEMU, XEN )로 가상 컴퓨터의 최상위에서 실행할 수 있습니다.

유형 2 : 애플리케이션 바이너리 인터페이스 (ABI) 가상 시스템 은 게스트 프로세스 ABI 에뮬레이션을 제공합니다. 그 ABI에 대한 애플리케이션은 네이티브 ABI 애플리케이션의 다른 프로세스 (예 : Itanium의 Intel IA-32 Execution Layer, X86 에뮬레이션을위한 Transmeta의 Code Morphing, PowerPC 에뮬레이션을위한 Apple의 Rosetta 변환 레이어) 와 나란히 프로세스에서 실행될 수 있습니다.

유형 3 : 가상 ISA 가상 머신 은 런타임 엔진을 제공하여 가상 ISA로 코딩 된 애플리케이션을 실행할 수 있습니다. 가상 ISA는 일반적으로 ISA 의미의 높은 수준과 제한된 범위를 정의하므로 가상 컴퓨터가 전체 컴퓨터 시스템 (예 : Sun Microsystem의 JVM, Microsoft의 공용 언어 런타임, Parrot Foundation의 Parrot 가상 컴퓨터) 을 에뮬레이트하지 않아도 됩니다.

유형 4 : 언어 가상 시스템 은 게스트 언어로 표현 된 프로그램을 실행하는 런타임 엔진을 제공합니다. 프로그램은 일반적으로 사전에 기계 코드로 완전히 컴파일되지 않고 게스트 언어의 소스 형식으로 가상 시스템에 제공됩니다. 런타임 엔진은 프로그램을 해석하거나 번역 할 필요가 있으며 또한 메모리 관리 (예 : Basic, Lisp, Tcl, Ruby 용 런타임 엔진) 와 같은 언어로 추상화 된 특정 기능을 수행해야합니다.

가상 머신 유형 간의 경계는 명확하지 않습니다. 예를 들어 언어 가상 컴퓨터는 프로그램을 일종의 가상 ISA로 컴파일 한 다음 해당 가상 ISA의 가상 컴퓨터에서 코드를 실행하여 가상 ISA 가상 컴퓨터 기술을 사용할 수도 있습니다.

BEAM 과 같은 많은 VM 디자인이 경계를 넘었습니다. 그들은 세 번째와 네 번째 범주 모두에 적합 할 수 있습니다.

출처:

  1. 위키피디아
  2. 가상 컴퓨터의 고급 설계 및 구현; Xlao-Feng LI


Erlang 프로세스는 Java에서 스레드가 녹색이므로 '녹색'이 아닙니다. Erlang 프로세스는 메모리를 공유하지 않는 구조이며 Erlang VM에 의해 유지 관리됩니다.

이상하게 들릴지 모르겠지만이 신문은 '오래되었습니다'(2007 년의 바이오 임에도 불구하고). 런타임 대기열 (동적 밸런싱 기능 및 기타 기능 포함)을 완전히 새로 처리 할 때 R13 릴리스가 모두 변경되었습니다. Ulf Wiger가 http://ulf.wiger.net/weblog/2009/01/23/erlang-programming-for-multicore/ 에 대해 발표 한 내용입니다.

정리하자면, 프로세스는 완전히 투명하므로 런타임 큐와 스케줄러의 수를 조정할 수 있지만 OS 구현은 영향을받지 않습니다. 왜 11 개의 스레드가 있는지 추측하고 싶지는 않습니다.

편집 : 나는 조금 OS에 대해 잘못이다 :

+S Schedulers:SchedulerOnline

SMP 지원이 활성화되었을 때 생성 할 스케줄러 스레드와 스케줄러 스레드의 양을 온라인으로 설정합니다.

두 값의 유효 범위는 1-1024입니다. Erlang 런타임 시스템이 구성된 논리적 프로세서 및 사용 가능한 논리 프로세서의 양을 결정할 수있는 경우 Scheduler는 기본적으로 논리 프로세서를 구성하고 SchedulersOnline 은 기본적으로 사용 가능한 논리 프로세서를 사용합니다. 그렇지 않으면 기본값이 1이됩니다 :SchedulerOnline 는 생략 될 수 있습니다 :SchedulerOnline 이 아닌 경우 :SchedulerOnline 가 생략 될 수 있으며 그 반대의 경우도 가능합니다. 온라인 스케줄러의 수는 erlang:system_flag(schedulers_online, SchedulersOnline) 를 통해 런타임에 변경할 수 있습니다.

...

이 플래그는 에뮬레이터에서 SMP 지원이 활성화되지 않은 경우 무시됩니다 ( -smp 플래그 참조).

여기에서 : http://www.erlang.org/doc/man/erl.html

EDIT2 : 많은 VM과 다수의 스케줄러에 대한 장단점에 대한 erlang-questions 메일 링리스트에 대한 흥미로운 토론. 불행히도 2008 년 이후로 새로운 OTP 릴리스가 크게 개선 된 것은 아닙니다. http://www.erlang.org/cgi-bin/ezmlm-cgi?4:mss:38165:200809:nbihpkepgjcfnffkoobf







erlang virtual-machine beam