Accounting-Response dependence
Hello, I have freeradius 2.1.12 installed on 64bit CentOS. Radius-Accounting messages are logged on MySql (I call mysql procedure to write into the table). When execution of mysql procedure takes a while, accounting-response is delayed to accounting-request according to the procedure execution delay. When MySQL goes down, accounting-response is sent immediately. Is it possible to configure accounting in such way that there actually would be no accounting-response in case MySQL fails? Regards, Rudolf. -- View this message in context: http://freeradius.1045715.n5.nabble.com/Accounting-Response-dependence-tp503... Sent from the FreeRadius - User mailing list archive at Nabble.com.
RudolfSusnik wrote:
When execution of mysql procedure takes a while, accounting-response is delayed to accounting-request according to the procedure execution delay.
That's how accounting works.
When MySQL goes down, accounting-response is sent immediately. Is it possible to configure accounting in such way that there actually would be no accounting-response in case MySQL fails?
Yes. sql if (fail) { do_not_respond } It's replying because you have the accounting section log to the "detail" file. What you really want is something like raddb/sites-available/buffered-sql Alan DeKok.
Effective solutions are usualy simple ;) Tnx Alan! Regards, Rudolf. -- View this message in context: http://freeradius.1045715.n5.nabble.com/Accounting-Response-dependence-tp503... Sent from the FreeRadius - User mailing list archive at Nabble.com.
Hi, I have a similar problem but the other way around. I have 4 gateways bombing thousands of packets/s at my freeradius server. I have it configured such that "default" writes packets in a detail file. "decoupled_accounting" site configuration tells it to read packets from detail file at load_factor = 100 (tests showed this value works best for me) then stored in mysql through a python script run via rlm_python (I run a very complex analysis on the H323AvGwRxdCdn and H323FinalXlatedCdn attributes). All is well when there's no load but at certain times it happens that one of the tables must be locked for 2 or 3 seconds (snapshot and purge on a memory table) and packets wait to be written because of the lock. Freeradius starts to spit warnings about packets hung in queue for more than x seconds then all hell breaks loose because the gateways retransmit these packets and it's all downhill from there. What can I do to make freeradius send an ok or something to the gateways as soon as the packets land in the detail file because once in the detail file I know for sure the packets will get into the database? Thanks, -- View this message in context: http://freeradius.1045715.n5.nabble.com/Accounting-Response-dependence-tp503... Sent from the FreeRadius - User mailing list archive at Nabble.com.
Hi,
I have 4 gateways bombing thousands of packets/s at my freeradius server. I have it configured such that "default" writes packets in a detail file. "decoupled_accounting" site configuration tells it to read packets from detail file at load_factor = 100 (tests showed this value works best for me) then stored in mysql through a python script run via rlm_python (I run a very complex analysis on the H323AvGwRxdCdn and H323FinalXlatedCdn attributes). All is well when there's no load but at certain times it happens that one of the tables must be locked for 2 or 3 seconds (snapshot and purge on a memory table) and packets wait to be written because of the lock. Freeradius starts to spit warnings about packets hung in queue for more than x seconds then all hell breaks loose because the gateways retransmit these packets and it's all downhill from there. What can I do to make freeradius send an ok or something to the gateways as soon as the packets land in the detail file because once in the detail file I know for sure the packets will get into the database?
have you tried the buffered_sql virtual-server instead? alan
Alan Buxey wrote
have you tried the buffered_sql virtual-server instead?
I don't use any sql in freeradius. I store the packet directly from rlm_python. I only use freeradius for its decoupled accounting. -- View this message in context: http://freeradius.1045715.n5.nabble.com/Accounting-Response-dependence-tp503... Sent from the FreeRadius - User mailing list archive at Nabble.com.
On Wed, Dec 14, 2011 at 7:03 AM, amne@netconnect.ro <amne@netconnect.ro> wrote:
Alan Buxey wrote
have you tried the buffered_sql virtual-server instead?
I don't use any sql in freeradius. I store the packet directly from rlm_python. I only use freeradius for its decoupled accounting.
Is the sql server on the same server as FR? If yes, that may be the source of your problem. Try decreasing load_factor (100? really?) or start FR with higher process priority (e.g using nice/renice) than the sql server. -- Fajar
amne@netconnect.ro wrote:
All is well when there's no load but at certain times it happens that one of the tables must be locked for 2 or 3 seconds
One response is to use a real database. Something as critical as a database shouldn't lock for 2-3 seconds.
(snapshot and purge on a memory table) and packets wait to be written because of the lock. Freeradius starts to spit warnings about packets hung in queue for more than x seconds then all hell breaks loose because the gateways retransmit these packets
Because you only have one server. Split the server into two processes. One listens on network sockets and writes to the detail file. It shouldn't do anything else. Another reads from the detail file and writes to SQL.
and it's all downhill from there. What can I do to make freeradius send an ok or something to the gateways as soon as the packets land in the detail file because once in the detail file I know for sure the packets will get into the database?
The problem isn't the detail file. The problem is that the server LOCKS, because all of the threads are locked, because the DB is locked. So it can't write to the detail file. Splitting the server into two processes fixes that. It allows one process to write to the detail file, even if the reader is down, or is locked for many seconds. Alan DeKok.
Alan DeKok-2 wrote
Because you only have one server. Split the server into two processes. One listens on network sockets and writes to the detail file. It shouldn't do anything else. Another reads from the detail file and writes to SQL.
I think this might just work will try it out today and see what's what. Alan DeKok-2 wrote
The problem isn't the detail file. The problem is that the server LOCKS, because all of the threads are locked, because the DB is locked. So it can't write to the detail file.
Splitting the server into two processes fixes that. It allows one process to write to the detail file, even if the reader is down, or is locked for many seconds.
I didn't say the detail file was at fault. I know the database is the culprit, but I just wanted a way to have packets written to the detail file regardless of the database then written to db at its own pace. Two processes seems like the best idea so far, I don't even know how I missed it. Cheers, amne -- View this message in context: http://freeradius.1045715.n5.nabble.com/Accounting-Response-dependence-tp503... Sent from the FreeRadius - User mailing list archive at Nabble.com.
participants (5)
-
Alan Buxey -
Alan DeKok -
amne＠netconnect.ro -
Fajar A. Nugraha -
RudolfSusnik