We've been seeing a leak for about year or more but it's ntlm_auth not radiator itself. We do about 1.8 million auths per day. Our servers have 4 GB RAM and radiator needs to be restarted 3 or 4 times a year.
--- Roberto Ullfig - rull...@uic.edu IT Technical Associate Enterprise Architecture and Development | ACCC University of Illinois - Chicago -----Original Message----- From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On Behalf Of Fredrik Pettai Sent: Tuesday, September 27, 2016 10:54 AM To: Heikki Vatiainen <h...@open.com.au> Cc: radiator@open.com.au Subject: Re: [RADIATOR] more memory leakage? > On 27 Sep 2016, at 11:32, Heikki Vatiainen <h...@open.com.au> wrote: > > On 26.9.2016 16.40, Fredrik Pettai wrote: > >> (A rough guestimate of the number of radius authentications handled >> by these servers is ~500.000 Accepts/Rejects per day, RADSEC is >> enabled/running too...) > > If you are using EAP and have not disabled session resumption, can you > try setting EAPTLS_SessionResumptionLimit to a non-default value, for > example 3600 or 7200 (1 hour or 2 hours)? > > This would go to AuthBy(s) where the other EAPTLS_* parameters are. > Now that the limit is no longer smaller of the EAP context timeout and > this value, the default value might be too high for sites that do a > lot of tunnelled EAP and end up caching a lot of sessions. Sorry, then I wrote authentication handled, I meant by proxying requests… These Radiators are just doing proxying inbetween all our IdP’s in .se (they are the FLRS's for .SE), and the eduroam ETLR’s (root) servers… Re, /P _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
