auto_limit_acct = boolean

no

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 = integer

65536

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 = integer

0

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 = integer

32

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 = integer

10

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 = integer

3

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 = integer

5

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