Weird issue - threads bottleneck in post-proxy section
loic.restoux at capgemini.com
Tue Mar 3 11:01:02 CET 2015
Le 02/03/2015 17:14, Alan DeKok wrote :
> What happens when you use the “ok” module instead of your custom one?
> It might be down to bad interactions with the scheduler.
Do you mean the "always" module ? No problem at all with it, the rate is
very good with an invocation in post-proxy section.
To be honest, we used custom-made modules for years without any problem,
but they all execute very quickly (around 2 or 3 ms). The issue seems to
appear if there are blocking (or time-consuming ?) operations in
post-proxy and I'm not sure it is related to modules. So far, we
encountered the issue with:
- rlm_rest requesting a high loaded REST server.
- rlm_exec invoking the /bin/sleep command (however in this case the
rate is as bad in pre-proxy as in post-proxy so we can't rely on the
- rlm_lrs which calls usleep().
During this tests, we do not see high CPU or memory consumption. This is
like FreeRadius have nothing to do.
If it's a scheduler problem, should we not see that all threads are
active, but blocked somewhere ?
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