From: Alan T. DeKok Date: Wed, 8 Aug 2018 13:26:49 +0000 (-0400) Subject: delete old documentation and write new docs X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3efea7aa2efe971c983cec2830f0cf9c055986f4;p=thirdparty%2Ffreeradius-server.git delete old documentation and write new docs for network / worker threads --- diff --git a/raddb/radiusd.conf.in b/raddb/radiusd.conf.in index bb8a1f69897..087c7e10e1e 100644 --- a/raddb/radiusd.conf.in +++ b/raddb/radiusd.conf.in @@ -443,160 +443,22 @@ $INCLUDE clients.conf # THREAD POOL CONFIGURATION # -# The thread pool is a long-lived group of threads which -# take turns (round-robin) handling any incoming requests. -# -# You probably want to have a few spare threads around, -# so that high-load situations can be handled immediately. If you -# don't have any spare threads, then the request handling will -# be delayed while a new thread is created, and added to the pool. -# -# You probably don't want too many spare threads around, -# otherwise they'll be sitting there taking up resources, and -# not doing anything productive. -# -# The numbers given below should be adequate for most situations. +# In v4, the thread pool does not change size dynamically. Instead, +# there are a small number of threads which read from the network, +# and a slightly larger number of threads which process a request. # thread pool { - # Number of servers to start initially --- should be a reasonable - # ballpark figure. - start_servers = 5 - - # Limit on the total number of servers running. - # - # If this limit is ever reached, clients will be LOCKED OUT, so it - # should NOT BE SET TOO LOW. It is intended mainly as a brake to - # keep a runaway server from taking the system with it as it spirals - # down... - # - # You may find that the server is regularly reaching the - # 'max_servers' number of threads, and that increasing - # 'max_servers' doesn't seem to make much difference. - # - # If this is the case, then the problem is MOST LIKELY that - # your 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: slow database, or 'hostname_lookups=yes'. - # - # For more information, see 'max_request_time', above. - # - max_servers = 32 - - # Server-pool size regulation. Rather than making you guess - # how many servers you need, 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. - # - # It 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. 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 = 3 - max_spare_servers = 10 - - # 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 will be 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 you can do other than make sure the server - # receives less traffic, or make sure that the database can - # handle the load. - # -# max_queue_size = 65536 - - # There may be memory leaks or resource allocation problems with - # the server. If so, set this value to 300 or so, so that the - # resources will be cleaned up periodically. - # - # This should only be necessary if there are serious bugs in the - # server which have not yet been fixed. - # - # '0' is a special value meaning 'infinity', or 'the servers never - # exit' - max_requests_per_server = 0 - - # Automatically limit 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/s received by the server for processing, and - # comparing that to the packets/s 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 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. - # - auto_limit_acct = no - - # In some cases, the "offered" load to the server can be - # higher than the "accepted" load. This usually happens - # when either the database back-end is overload, or when - # 10,000 users log in at the same time. - # - # When the server cannot process packets quickly enough, - # the incoming packets are placed onto a queue for later - # processing. These packets are ordered by priority, - # which is configurable. The different priorities allow - # you to control how the server behaves in overload - # situations. As not everyones needs are the same, - # we offer multiple options for priority calculations. - # - # time Order packets by when they are received - # Note that replies from a home server - # are ordered by when the *original* - # packet came in, so they are prioritized. - # - # default Order by listener type - # proxy > auth > acct > detail > coa - # Packets from the same listener are - # ordered by "time". - # - # eap Order by ongoing EAP sessions. - # EAP authentication takes multiple - # rounds. This priority ensures - # that EAP sessions which are "further along" - # in the authentication process are - # handled with a higher priority. - # Packets with the same eap priority - # are ordered by "default" - # - # For systems which are doing EAP / 802.1X authentication - # and not accounting, we recommend using "eap". If most - # of the packets are proxied, you should NOT use "eap". - # - # The danger with the prioritization process is that - # in overload situations, the "eap" priority can cause - # accounting packets to be ignored for extended periods - # of time, until the EAP overload stops. - # - # However, setting the "eap" priority ensures that users - # can get on the net as quickly as possible, which is - # usually what you want. - # - queue_priority = default + # + # Only one network thread is supported for now + # + num_networks = 1 + # + # The worker threads can be varied. It should be at least one, + # and no more than 32. Since each request is non-blocking, + # there is no reason to run hundreds of threads as in v3. + # + num_workers = 4 } ######################################################################