Thread Pool Configuration

The thread pool is a long-lived group of threads that take turns (round-robin) handling any incoming requests.

It is a good idea to have a few spare threads around so that high-load situations can be handled immediately. If there aren’t any spare threads, then the request handling will be delayed while a new thread is created and added to the pool.

Too many spare threads are not a good idea, as they’ll be sitting there taking up resources and not doing anything productive.

The numbers given below should be adequate for most situations.

Directives

auto_limit_acct
Syntax

auto_limit_acct = boolean

Default

no

Description

Automatically limits the number of accounting requests. This configuration item tracks how many requests per second the server can handle. It does this by tracking the packets received by the server for processing and comparing them to the packets handled by the child threads.

If the received PPS is larger than the processed PPS and the queue is more than half full, then new accounting requests are probabilistically discarded. This lowers the number of packets that the server needs to process. Over time, the server will "catch up" with the traffic.

Throwing away accounting packets is usually safe and low impact. The NAS will retransmit them in a few seconds or even in a few minutes. Vendors should read RFC 5080 Section 2.2.1 to see how accounting packets should be retransmitted. Using any other method is likely to cause network meltdowns.

max_queue_size
Syntax

max_queue_size = integer

Default

65536

Description

When the server receives a packet, it places it onto an internal queue, where the worker threads (configured above) pick it up for processing. The maximum size of that queue is given here.

When the queue is full, any new packets are silently discarded.

The most common cause of the queue being full is that the server is dependent on a slow database and it has received a large "spike" of traffic. When that happens, there is very little that can be done other than ensurin the server receives less traffic or ensuring that the database can handle the load.

max_requests_per_server
Syntax

max_requests_per_server = integer

Default

0

Description

There may be memory leaks or resource allocation problems with the server. If so, set this value to approximately 300 so that the resources will be cleaned up periodically.

This should only be necessary if there are serious bugs in the server that have not yet been fixed.

'0' is a special value meaning 'infinity' or 'the servers never exit'.

max_servers
Syntax

max_servers = integer

Default

32

Description

Limit on the total number of servers running.

If this limit is ever reached, clients will be locked out, so max_servers should not be set too low. This number is intended mainly as a brake to keep a runaway server from taking the system with it as it spirals down.

Sometimes the server regularly reaches the max_servers number of threads and increasing max_servers doesn’t seem to make much difference.

If this is the case, then the problem is most likely that the back-end databases are taking too long to respond and are preventing the server from responding in a timely manner.

The solution is NOT do keep increasing the max_servers value, but instead to fix the underlying cause of the problem: a slow database, or hostname_lookups=yes.

For more information, see max_request_time.

max_spare_servers
Syntax

max_spare_servers = integer

Default

10

Description

Server-pool size regulation. Rather guessing how many servers are needed, FreeRADIUS dynamically adapts to the load it sees; that is, it tries to maintain enough servers to handle the current load plus a few spare servers to handle transient load spikes.

FreeRADIUS does this by periodically checking how many servers are waiting for a request. If there are more than max_spare_servers, some of the spares die off. The default values are probably OK for most sites.

min_spare_servers
Syntax

min_spare_servers = integer

Default

3

Description

Server-pool size regulation. Rather guessing how many servers are needed, FreeRADIUS dynamically adapts to the load it sees; that is, it tries to maintain enough servers to handle the current load plus a few spare servers to handle transient load spikes.

FreeRADIUS does this by periodically checking how many servers are waiting for a request. If there are fewer than min_spare_servers, it creates a new spare. The default values are probably OK for most sites.

start_servers
Syntax

start_servers = integer

Default

5

Description

The number of servers to start initially. This number should be a reasonable ballpark figure.