high performance FR installation and unfinished requests
Hi, we have a FR server (version 1.1.7) on a Redhat machine. We use it for dumping accouting requests into a database. We have about 200 requests per second in average. Once in a while (1 per minute) we see a error in the log file: Discarding duplicate request from client ... due to unfinished request .... Does the FR server drop accouting requests? How can we monitor how any requests the RADIUS server gets? Is this anything to worry? Thanks for any help. -- Dr. Michael Schwartzkopff MultiNET Services GmbH Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany Tel: +49 - 89 - 45 69 11 0 Fax: +49 - 89 - 45 69 11 21 mob: +49 - 174 - 343 28 75 mail: misch@multinet.de web: www.multinet.de Sitz der Gesellschaft: 85630 Grasbrunn Registergericht: Amtsgericht München HRB 114375 Geschäftsführer: Günter Jurgeneit, Hubert Martens --- PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B Skype: misch42
200 requests per second is not much for freeradius but it's a lot for the database. It's highly likely that the database can't cope. Ivan Kalik Kalik Informatika ISP Dana 17/6/2008, "Michael Schwartzkopff" <misch@multinet.de> piše:
Hi,
we have a FR server (version 1.1.7) on a Redhat machine. We use it for dumping accouting requests into a database. We have about 200 requests per second in average.
Once in a while (1 per minute) we see a error in the log file: Discarding duplicate request from client ... due to unfinished request ....
Does the FR server drop accouting requests? How can we monitor how any requests the RADIUS server gets? Is this anything to worry?
Thanks for any help.
-- Dr. Michael Schwartzkopff MultiNET Services GmbH Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany Tel: +49 - 89 - 45 69 11 0 Fax: +49 - 89 - 45 69 11 21 mob: +49 - 174 - 343 28 75
mail: misch@multinet.de web: www.multinet.de
Sitz der Gesellschaft: 85630 Grasbrunn Registergericht: Amtsgericht München HRB 114375 Geschäftsführer: Günter Jurgeneit, Hubert Martens
---
PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B Skype: misch42
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Am Dienstag, 17. Juni 2008 15:00 schrieb Ivan Kalik:
200 requests per second is not much for freeradius but it's a lot for the database. It's highly likely that the database can't cope.
We check this. DB response 3ms and the DB has 1000 threads. So no problem here. -- Dr. Michael Schwartzkopff MultiNET Services GmbH Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany Tel: +49 - 89 - 45 69 11 0 Fax: +49 - 89 - 45 69 11 21 mob: +49 - 174 - 343 28 75 mail: misch@multinet.de web: www.multinet.de Sitz der Gesellschaft: 85630 Grasbrunn Registergericht: Amtsgericht München HRB 114375 Geschäftsführer: Günter Jurgeneit, Hubert Martens --- PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B Skype: misch42
Your response time must always be fast enough. If the DB lags at any time you will have the timeout problem. Typically, this can occur during checkpoints or other heavy I/O periods. What is the response time under load? Ken On Tue, Jun 17, 2008 at 03:08:39PM +0200, Michael Schwartzkopff wrote:
Am Dienstag, 17. Juni 2008 15:00 schrieb Ivan Kalik:
200 requests per second is not much for freeradius but it's a lot for the database. It's highly likely that the database can't cope.
We check this. DB response 3ms and the DB has 1000 threads. So no problem here.
-- Dr. Michael Schwartzkopff MultiNET Services GmbH Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany Tel: +49 - 89 - 45 69 11 0 Fax: +49 - 89 - 45 69 11 21 mob: +49 - 174 - 343 28 75
mail: misch@multinet.de web: www.multinet.de
Sitz der Gesellschaft: 85630 Grasbrunn Registergericht: Amtsgericht M?nchen HRB 114375 Gesch?ftsf?hrer: G?nter Jurgeneit, Hubert Martens
---
PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B Skype: misch42
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Michael Schwartzkopff wrote:
we have a FR server (version 1.1.7) on a Redhat machine. We use it for dumping accouting requests into a database. We have about 200 requests per second in average.
Once in a while (1 per minute) we see a error in the log file: Discarding duplicate request from client ... due to unfinished request ....
The client hasn't received a response to the request, and is re-sending it. i.e. the request has taken LONGER than the client's timeout, usually 5 seconds or so. That indicates a pretty significant backlog of requests at 200 packets/s. It likely means that your system us barely keeping up with the load.
Does the FR server drop accouting requests?
No. But accounting requests should *not* be re-transmitted by the NAS. If the NAS does this, it often means that they don't quite follow the RADIUS standards.
How can we monitor how any requests the RADIUS server gets? Is this anything to worry?
You probably want to double-check your database. Tune it, optimize it, upgrade the hardware, whatever. Alan DeKok.
Am Dienstag, 17. Juni 2008 15:05 schrieb Alan DeKok:
How can we monitor how any requests the RADIUS server gets? Is this anything to worry?
You probably want to double-check your database. Tune it, optimize it, upgrade the hardware, whatever.
Thanks for you mail. Is there any utility in FR to look after the actual performace? Like requests per second, backlog queue, ... Thanks. -- Dr. Michael Schwartzkopff MultiNET Services GmbH Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany Tel: +49 - 89 - 45 69 11 0 Fax: +49 - 89 - 45 69 11 21 mob: +49 - 174 - 343 28 75 mail: misch@multinet.de web: www.multinet.de Sitz der Gesellschaft: 85630 Grasbrunn Registergericht: Amtsgericht München HRB 114375 Geschäftsführer: Günter Jurgeneit, Hubert Martens --- PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B Skype: misch42
Am Dienstag, 17. Juni 2008 15:05 schrieb Alan DeKok:
Michael Schwartzkopff wrote:
we have a FR server (version 1.1.7) on a Redhat machine. We use it for dumping accouting requests into a database. We have about 200 requests per second in average.
Once in a while (1 per minute) we see a error in the log file: Discarding duplicate request from client ... due to unfinished request ....
The client hasn't received a response to the request, and is re-sending it. i.e. the request has taken LONGER than the client's timeout, usually 5 seconds or so.
That indicates a pretty significant backlog of requests at 200 packets/s. It likely means that your system us barely keeping up with the load.
Does the FR server drop accouting requests?
No. But accounting requests should *not* be re-transmitted by the NAS. If the NAS does this, it often means that they don't quite follow the RADIUS standards.
How can we monitor how any requests the RADIUS server gets? Is this anything to worry?
You probably want to double-check your database. Tune it, optimize it, upgrade the hardware, whatever.
Alan DeKok.
OK. We are testing with sql_log. The system load ist significant lower now. Uptime went from 0.3 to 0.05. But still we see the same amout of "error duplicate packets" in the radius log. I would not be worried at all about that, the the CPU load of the NAS (radius client) is 100%. Perhaps the client drops the accout reply packets? -- Dr. Michael Schwartzkopff MultiNET Services GmbH Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany Tel: +49 - 89 - 45 69 11 0 Fax: +49 - 89 - 45 69 11 21 mob: +49 - 174 - 343 28 75 mail: misch@multinet.de web: www.multinet.de Sitz der Gesellschaft: 85630 Grasbrunn Registergericht: Amtsgericht München HRB 114375 Geschäftsführer: Günter Jurgeneit, Hubert Martens --- PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B Skype: misch42
Michael Schwartzkopff wrote:
OK. We are testing with sql_log. The system load ist significant lower now. Uptime went from 0.3 to 0.05.
That's nice.
But still we see the same amout of "error duplicate packets" in the radius log.
That's not.
I would not be worried at all about that, the the CPU load of the NAS (radius client) is 100%. Perhaps the client drops the accout reply packets?
Ah. Yes, that could be the case. Alan DeKok.
participants (4)
-
Alan DeKok -
Ivan Kalik -
Kenneth Marshall -
Michael Schwartzkopff