Weird issue - threads bottleneck in post-proxy section
loic.restoux at capgemini.com
Tue Mar 3 12:00:48 CET 2015
Le 03/03/2015 11:01, "RESTOUX, Loïc" wrote :
> If it's a scheduler problem, should we not see that all threads are
> active, but blocked somewhere ?
Another thoughts about this: a network analysis seems to show that the
bottleneck is not in post-proxy handling, but upstream. We know that
radperf is sending as much requests as we told him (with -p 500
argument), but the rate of outgoing proxied requests is far lower.
See the graphs above:
- rlm_lrs invoked in pre-proxy section:
- rlm_lrs invoked in post-proxy section:
So, is it possible that FreeRadius slows down the proxied requests sent
to the remote radius, for instance in order to be sure to have always
enough available threads to deal with the responses ?
Note that our max_outstanding parameter is set to 4096. Should we care
of other parameters in the proxy section ?
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
More information about the Freeradius-Users