RE: Re: interaction between Virtual server & Authorize section
Hi Fajar and Alan Yes, I noticed that it said discarding *duplicate* request from our NMS. About how fast our NMS request to FR, just like I mentioned before about it send a request w/ 2 retry & 1 sec timeout every minute. This request will proxy to external AAA for auth and I've confirmed the AAA is normal. We're guessing the problem is due to abnormal IO overloading of our new DB. Another, our NMS always send the same request w/ the same ID, if it didn't get response from FR with 2 retry & 1 sec TO, it will trigger trap to send SMS to us. I'm afraid that sometimes our NMS would get a chance to finish a request under the circumstance of bad DB situation which other virtual server is facing. At the same time, FR possibly be late to return a response to it so that our test client will consider as RADIUS is down. And I guess FR will queue the reply with the ID. After a minute, it might ignore the request from our NMS because previous request w/ same ID is still in the queue. Then this has been a cycle. In summary, I just want to confirm if I can assert it was caused by problematic DB when I got the error message like that. But since Alan has said that I can put more focus on what happened to DB. Thanks you guys' experiences a lot! Besides, I want to know how much extent that does perl script in FR would likely decrease performance of overall FR significantly? Because I also wrote some modules by rlm_perl in different sections. I know documentation says perl with FR is fast. But I have no idea if there is a limitation. Thanks again! Okis On Mon, Oct 21, 2013 at 3:48 PM, Okis Chuang < <http://freeradius.1045715.n5.nabble.com/user/SendEmail.jtp?type=node&node=5 723064&i=0> [hidden email]> wrote: "Discarding duplicate request from NMS - ID xx due to unfinished request xxxx", Did you read what it says? "Duplicate request"? then after about short period of time, it showed msg "WARNING: Unresponsive child for request xxxx, in component authorized module", can I still say that is due to problematic DB? Do you actually know how fast your NMS request is processed? It can be slow even if it doesn't use db if it depends on external components. For example, proxying auth to external radius servers. -- Fajar
On Tue, Oct 22, 2013 at 2:53 PM, Okis Chuang <okischuang@outlook.com> wrote:
Hi Fajar and Alan
****
Yes, I noticed that it said discarding **duplicate** request from our NMS. ****
About how fast our NMS request to FR, just like I mentioned before about it send a request w/ 2 retry & 1 sec timeout every minute.****
This request will proxy to external AAA for auth and I’ve confirmed the AAA is normal.****
**
... and how did you confirm the external radius is "normal"? Sending acces-request from the radius server (i.e. using radtest/radclient) to the external radius is a good way to test.
**
We’re guessing the problem is due to abnormal IO overloading of our new DB.
You were given a suggestion to limit num_sql_socks. Have you done that? If you had, it would've limit the resource (e.g. threads) used by FR interacting to the db, and it should leave FR with enough resources to do other things. -- Fajar
Okis Chuang wrote:
We’re guessing the problem is due to abnormal IO overloading of our new DB.
Don't guess. Find out what's wrong, and fix it.
In summary, I just want to confirm if I can assert it was caused by problematic DB when I got the error message like that.
Almost always. Or, a blocked Perl script.
Besides, I want to know how much extent that does perl script in FR would likely decrease performance of overall FR significantly?
It depends on your script. If your script does DNS lookups, or network connections to other systems... yes, it can block the server. Alan DeKok.
participants (3)
-
Alan DeKok -
Fajar A. Nugraha -
Okis Chuang