@Kargol Meister Ambari internally uses "Jetty" server where we have "acceptors" and "selector" threads just like any other servers.
From Jetty9 the formula for calculating the "acceptors" and "selector" threads are much more enhanced and changed. Some informations regarding "acceptors" and "selector": Acceptor threads accepts new connections from client. They run a loop on a blocking accept() call to accept connections. With a box with 80 cores, which is not typical, you are recommended to manually configure the number of acceptors and selectors, since the guesses we make are probably off. The right number of acceptor threads is determined by the server load and the traffic shape, in particular by connection open/close rate. We can higher this rate, the more acceptors you want. Selector threads manage events on connected sockets. Every time a socket connects, the acceptor threads accepts the connection and assign the socket to a selector, chosen in a round robin fashion. The selector is responsible to detect activity on that socket (I/O events such as read availability and write availability) and signal that event to other code in Jetty that will handle the event. One thread runs one selector. This is basic async I/O using selectors. If you have a very busy server (say 100k connected clients at any time or more), If you want to "spread" those clients among many selectors, so that each selector will handle a portion of the connected clients and be faster in responding to client activity.
From Ambari 2.5.0 onwards the logic is much enhanced as part of : https://issues.apache.org/jira/browse/AMBARI-18827 to avoid blocking of ambari agent restart for hosts where we have higher number of cores. Now from ambari 2.5 the formula will be following for configuring the threadpool: configureJettyThreadPool(serverForAgent, acceptors * 2, AGENT_THREAD_POOL_NAME, configs.getAgentThreadPoolSize());
The AGENT_THREADPOOL_SIZE is controlled by the "agent.threadpool.size.max" (default value is 25) property [1]
"agent.threadpool.size.max" sets max number of threads used to process heartbeats from ambari agents and view.extraction.threadpool.size.max - for Views UI. The CLIENT_THREADPOOL_SIZE is controlled by the "client.threadpool.size.max" property [2] used for REST API calls: We might use: totalCPUs=Number of CPU cores on host machine
client.threadpool.size.max=totalCPUs+1
agent.threadpool.size.max=totalCPUs+1 .
[1] https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java#L2035-L2036 [2] https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java#L2020
... View more
