##以下观察是基于版本otp_19.1
#观察SMP enabled
Step 1. 启动erl with SMP enabled (erl -smp enable)
sexxx484: ~/erlang/test > erl
Erlang/OTP 19 [erts-8.1] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]
Eshell V8.1 (abort with ^G)
1>
#[smp:8:8] 表示在8核的机器上启动了8个scheduler, 每个core对应一个scheduler, 每一个scheduler对应于独立的一个操作系统线程. 启动erlang的时候可以通过选项 +S来设置启动多少个scheduler, 也可以在运行时通过erlang:system_flag 来调整.
Note: the results are similar whether symmetric multiprocessing is enabled or not. To prove it, you can just test it out by starting the Erlang VM with $ erl -smp disable
.
To see if your Erlang VM runs with or without SMP support in the first place, start a new VM without any options and look for the first line output. If you can spot the text [smp:2:2] [rq:2], it means you're running with SMP enabled, and that you have 2 run queues (rq, or schedulers) running on two cores. If you only see [rq:1], it means you're running with SMP disabled.
If you wanted to know, [smp:2:2] means there are two cores available, with two schedulers. [rq:2] means there are two run queues active. In earlier versions of Erlang, you could have multiple schedulers, but with only one shared run queue. Since R13B, there is one run queue per scheduler by default; this allows for better parallelism.
#[async-threads:10] 表示启动了异步线程池, 含有10个异步IO线程. 启动erlang的时候可以通过选项+A来设置启动多少个异步IO线程.
既然说到async thread pool, 这里就解释一下,这个异步线程池的作用. 当你有大量的文件IO操作的时候,这个异步线程池可以改善系统的响应效率,因为这些相对比较耗时的IO操作都放到异步线程池里面来完成了,不会影响到正常的scheduler调度.
下面一段话引用自stackoverflow.
The BEAM runs Erlang code in special threads it calls schedulers. By default it will start a scheduler for every core in your processor. This can be controlled and start up time, for instance if you don't want to run Erlang on all cores but "reserve" some for other things. Normally when you do a file I/O operation then it is run in a scheduler and as file I/O operations are relatively slow they will block that scheduler while they are running. Which can affect the real-time properties. Normally you don't do that much file I/O so it is not a problem.
The asynchronous thread pool are OS threads which are used for I/O operations. Normally the pool is empty but if you use the +A at startup time then the BEAM will create extra threads for this pool. These threads will then only be used for file I/O operations which means that the scheduler threads will no longer block w