Question

I have been reading the documentation trying to understand when it makes sense to increase the async-thread pool size via the +A N switch.

I am perfectly prepared to benchmark, but I was wondering if there were a rule-of-thumb for when one ought to suspect that growing the pool size from 0 to N (or N to N+M) would be helpful.

Thanks

Answer 1

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 waiting for file I/O and the real-time properties are improved. Of course this costs as OS threads aren’t free. The threads don’t mix so scheduler threads are just scheduler threads and async threads are just async threads.

If you are writing linked-in drivers for ports these can also use the async thread pool. But you have to detect when they have been started yourself.

How many you need is very much up to your application. By default none are started. Like @demeshchuk I have also heard that Riak likes to have a large async thread pool as they open many files. My only advice is to try it and measure. As with all optimisation?