Thanks for replying Alan, I have found the issue in my case, I was using external LDAP with radius and if LDAP is down then for the same EAP requests multiple authentication sessions were getting created. And as the cleanup of eap requests is plugged in processing of a reply message, this makes the cleanup happen only when a successful EAP request goes through. I am thinking to put a cleanup in session creation path also which cleans very old sessions( double of usual timer limit 20 seconds. So I guess this will not impact any ongoing EAP request(not making to go to "no state variable" state for EAP request, an early delete of an handler). Thanks, Kunal Solanki On Wed, 23 Jun 2010 16:12:33 +0530 wrote
Kunal Solanki wrote:
I have been using freeradius version 2.1.4 and when I upgraded to 2.1.7
I am facing issues of high memory usage by radiusd. In 2.1.4 also the
memory usage was quite high under high load but it used to come down
after some time when abandoned requests are cleaned up. The cleanup
trigger is not timer based in freeradius and is part of ongoing
requests. In 2.1.7 version somehow this cleanup doesn't happen
effectively and looks like for the same EAP requests a lot of dangling
handlers are created which are not getting cleaned.
You can instrument the code to see when they're getting cleaned up. Or, edit it to clean up *more* of them at a time.
I tried to cleanup
old handlers in src/modules/rlm_eap/mem.c but that causes other
side-affects of requests being present and no matching session state
variable found for that.
Uh... all you need to do is to change the "for" loop in eaplist_expire, to loop over more entries.
I believe in src/main/event.c we should have some sought of cleanup for
the old requests itself.
No. The server event loop doesn't deal with modules. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html