just two questions

[Arran Cudbard-Bell]

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 10.255.251.2 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

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>