Re: FreeRadius Losing packets in Multi-Threads mode
Hello, On Tue, 25 Oct 2011 21:09:31 +0100, Alan Buxey <A.L.M.Buxey@lboro.ac.uk>
however, as Alan said. in single thread mode, you only have one process dealing with requests.....so one single open connection to SQL, one single sesion to LDAP etc etc (whatever you use) - eg even a local file with PERL.
with multithread mode, you have many threads - all of which can be
hitting
your SQL or LDAP at same time...or trying to write to the same file in a PERL module....so you have to look at the speed/ability of your backend....the jump from a single query ata time to concurrent queries may have tipped your balance
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Here is what I had thought about: FreeRadius correctly treats the requests (answer are always received), but there is a locking problem with the log files, meaning that basically, only one thread can write inside. Is there any solution about that? As stated before, there is no overloading problem on the server. Running in single thread could be a solution, but it's really slow compared to multi-thread ... Regards, Pierre
Did the very same test here, with very same results. I find this a little bit scary to imagine that some accounting packets are lost (meaning I have no "proof" the requests was answered and how. regards Le 26/10/2011 10:21, Pierre Rondou a écrit :
Hello,
On Tue, 25 Oct 2011 21:09:31 +0100, Alan Buxey<A.L.M.Buxey@lboro.ac.uk>
however, as Alan said. in single thread mode, you only have one process dealing with requests.....so one single open connection to SQL, one single sesion to LDAP etc etc (whatever you use) - eg even a local file with PERL.
with multithread mode, you have many threads - all of which can be hitting your SQL or LDAP at same time...or trying to write to the same file in a PERL module....so you have to look at the speed/ability of your backend....the jump from a single query ata time to concurrent queries may have tipped your balance
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Here is what I had thought about: FreeRadius correctly treats the requests (answer are always received), but there is a locking problem with the log files, meaning that basically, only one thread can write inside.
Is there any solution about that? As stated before, there is no overloading problem on the server.
Running in single thread could be a solution, but it's really slow compared to multi-thread ...
Regards,
Pierre - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- <http://www.horoa.net> Alexandre Chapellon Ingénierie des systèmes open sources et réseaux. Follow me on twitter: @alxgomz <http://www.twitter.com/alxgomz>
Alexandre Chapellon wrote:
Did the very same test here, with very same results. I find this a little bit scary to imagine that some accounting packets are lost (meaning I have no "proof" the requests was answered and how.
Ah... after thinking about it some more, there is no problem. The test is wrong. Accounting packets have *nothing* which makes them unique, other than the packet contents. If you're sending the same packet over and over, it's a duplicate, and gets a duplicate response. In single threaded mode, the server receives a packet, sends a reply, and *deletes* all knowledge about the packet. When it receives the next one, it gets processed as if it was a new packet. In multi-threaded mode, the server receives a packet, hands it to a thread, which processes it and sends a reply. Crucially, the packet isn't deleted until later, because the server avoids thread locks. While the packet is cached, the main thread receives a "new" packet, which looks *exactly* the same as a packet in the cache. So... the main thread re-sends the same reply. If you look at the statistics from the server, you'll see the "duplicate request" counter being very high. It SHOULD be zero for accounting packets. Alan DeKok.
Pierre Rondou wrote:
Here is what I had thought about: FreeRadius correctly treats the requests (answer are always received), but there is a locking problem with the log files, meaning that basically, only one thread can write inside.
Edit raddb/detail, and add "locking = yes" Alan DeKok.
participants (3)
-
Alan DeKok -
Alexandre Chapellon -
Pierre Rondou