just two questions

Arran Cudbard-Bell a.cudbardb at freeradius.org
Thu Jun 12 11:42:18 CEST 2014

On 12 Jun 2014, at 07:59, Chris Knipe <savage at savage.za.org> wrote:

> Hi All,
> From the radmin command,  I can see the following
> radmin> stats socket 1812
>        requests        645589
>        responses       641483
>        accepts         359013
>        rejects         282470
>        challenges      0
>        dup             0
>        invalid         0
>        malformed       0
>        bad_authenticator       0
>        dropped         3110
>        unknown_types   0
>        last_packet     1402555332
>        elapsed.1us     0
>        elapsed.10us    0
>        elapsed.100us   0
>        elapsed.1ms     0
>        elapsed.10ms    229378
>        elapsed.100ms   384248
>        elapsed.1s      27768
>        elapsed.10s     86
> Now given my specific application that I use Radius for, the elapsed times
> are OK for the majority of requests (the sub 100ms range is fine).  I just
> have a quick question and a thought perhaps. 
> Under what circumstances will FR "drop" a request (i.e. dropped 3110).
> Also, would it be possible to be able to get stats for the thread pool
> through radmin as well?

When they take an excessively long time to complete, when the request queue
is full, when there's already a request in the request queue matching the
incoming request which has not yet been processed.

There may be more, Alan D will know.

> I've been experiencing very weird, intermittent and seemingly random
> timeouts from FR, and after increasing (doubling) the size of my thread
> pool, most of my issues seemed to have gone away.

Check your database. FreeRADIUS worker threads block on database queries,
if your database takes a long time to respond all the workers can block,
and cause the request queue to overflow.

>  Surely, those kind of
> stats in terms of the thread pool will not only be very helpful, but it will
> be absolutely beneficial in terms of debugging performance issues?

There are already events logged when a module take excessively long the 
process a request.

> Also as a last note, maybe something like a "slow query" log option can be
> added as well, where we can log auth/acct requests to a while in instances
> where FR takes longer than a specific amount of time to process?  Say, if it
> takes longer than 100ms to process a request, log the request to a specific
> file?  Not only will it again help to troubleshoot and isolate performance
> issues, but it could possibly also mean that the entire server does not need
> to be run in debug mode to identify requests which takes long to process.

Use v3.0.x radsniff, it already has the capability to print out the requests 
which have timed out.


Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140612/a2f4af9f/attachment.pgp>

More information about the Freeradius-Users mailing list