@cohult Thank you! This is finally working 
1 Like
Lots of good info, but this part isn’t quite correct, and may be very relevant in particular for ConfD users:
The processes that are exposed to the Erlang programmer are very light-weight, and can be thought of as user-level threads execution-wise (but they do not share memory from the Erlang point of view). However the Erlang VM a.k.a. “beam” has very good support for multi-core, which is essentially transparent to the Erlang programmer. This is achieved through “scheduler threads”, which correspond to OS threads, and schedule&run the individual Erlang processes. By default, the Erlang VM will run as many scheduler threads as there are cores available in the system, which is probably optimal for achieving maximum performance.
However the number of scheduler threads to run is configurable, and both NSO and ConfD expose this through the --smp option (see ncs(1) and/or confd(1)). Additionally, while NSO uses the default value for the Erlang VM, the ConfD default is 1. One reason for this is that systems running ConfD may be quite resource-constrained, with configuration management not being a top priority, and thus it may not be desirable to have ConfD spreading its load across all cores.
Bottom line: ConfD does indeed limit itself to one core as described by @Ivo by default, but this can be changed through the --smp option,
1 Like