error discarding packet

[Alisson]

hi, my DB is ok I tested with another programms e etc, and is running well

how I set the thread pool to better concurrency?

2009/12/23 Borislav Dimitrov <b.dimitrov at ngsystems.net>

> Hi,
>
> This question has been answered many times on this ML. I myself have (at
> least tried) answered it two times. Here're some of my previous messages:
>
> Msg1:
> Hi,
>
> I've already tried to answer a similar question some time ago (and I'm
> probably not the only one) but anyways...
> The cause of the problems probably is some delay or packet loss or
> something like that. Notice the Acct-Delay-Time value increasing as the NAS
> retries to send the "lost" accounting packet (although - at least in my case
> - it wasn't lost but just its processing was delayed). I've experienced such
> issues with Cisco VoIP routers - the router's log is flooded with RADIUS
> Server DEAD - and then ... ALIVE messages and in the FR log you can see the
> retries with the values of Acct-Delay-Time increasing. The main cause of the
> problem may be different, so you'll have to check it in your case. In my
> case it was caused by the thread pool settings not being appropriate for the
> load. In this case the CPU usage stays low but it's not used because you
> cannot achieve good concurrency and request have to await each other to
> finish. So find the main cause for your problems and eliminate it. The other
> thing is that most NASs have options to configure the RADIUS timeout, dead,
> retransmit etc times. E.g.for Cisco you could try "radius-server retransmit
> 0".
>
> Msg2:
> Hi,
>
> As far as I can see, the people on the list have provided you with a lot of
> very useful suggestions on what could cause the problem. As I said earlier
> (let me clarify) and to help you narrow things a little bit - it's probably
> due to the RADIUS response timing out hence the NAS complains the server is
> dead and later when it responds finally it marks it as alive again. The
> reasons can be different depending on your setup - slow network, database,
> custom module (like rlm_perl/python etc) or as I suggested (from my personal
> experiences) improperly configured concurrence settings of FR itself. See
> which component of your setup is causing the slow responds (it can be the
> backend, or messed up FR configuration) and fix it. Just for completeness
> check your NASs manuals - most have these settings configurable - response
> timeouts, retransmits, marking the server as dead etc but playing with the
> NAS while possibly useful is probably not the main issue in your setup -
> check what is slowing things down.
>
> Msg3:
> Hi there,
>
> I may be mistaken but... these are log message on the NAS aren't they?
> If this is the case, I've experienced similar behavior with Cisco VoIP
> routers (RADIUS Server DEAD and then... ALIVE). This happens if you haven't
> properly enabled concurrency in FreeRADIUS - the CPU usage stays low
> 0%-1%-2% but if the requests are many they are obviously waiting each
> other... This happens when you have stared FreeRADIUS with the -X key (I
> think it starts with a single thread then) or have too low values for the
> thread pool parameters (and/or the *_clones options of rlm_perl which are to
> be deprecated soon). If you configure proper values according to the
> expected usage (concurrent requests), then the request won't wait each other
> to finish while the CPU stays unused and you'll avoid this annoying message
> in your logs. A sure sing that something like that is going on is the
> Acct-Delay-Time parameter with values greater than 0 - that is for
> accounting not sure for auth etc. Anyways if the values of that parameter
> are high (they are in seconds I think) then the requests are waiting too
> long and hence the error messages.
>
> Bottom line:
> 1) Check the ML for more info
> 2) The NAS can be configured when to timeout and resend the RADIUS packages
> 3) Something is slowing down your setup. It may be the DB or something
> else. If your CPU usage stays low (< 5%), check your thread pool settings
> and increase them to achieve better concurrency.
>
> Sincerely,
>
> Borislav Dimitrov
> e-mail: b.dimitrov at ngsystems.net
> GSM: 0888 51 55 45; 0889 28 54 57
> NG Systems
> Lavele 32 str, fl: 4,
> Sofia, Bulgaria
>
>
>
>
> On 23.12.2009, at 15:10, Alisson wrote:
>
>  hi, in another day I posted this same error ' Error: Discarding duplicate
>> request from client '
>>
>> and the answer was 'your database is slow'
>>
>> so I upgrade my server with more memory, and changed servers variables...
>>
>> but, i'm still having this problem
>>
>> and I dont know what can be
>>
>> --
>> Att.
>> Alisson F. Gonçalves
>> Sistemas de Informação - UFGD
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>



-- 
Att.
Alisson F. Gonçalves
Sistemas de Informação - UFGD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20091223/f6acc0a0/attachment.html>