[RADIATOR] more memory leakage?

Ullfig, Roberto Alfredo rullfig at uic.edu
Wed Sep 28 08:11:10 CDT 2016

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 - rullfig at uic.edu
IT Technical Associate
Enterprise Architecture and Development | ACCC
University of Illinois - Chicago

-----Original Message-----
From: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au] On Behalf Of Fredrik Pettai
Sent: Tuesday, September 27, 2016 10:54 AM
To: Heikki Vatiainen <hvn at open.com.au>
Cc: radiator at open.com.au
Subject: Re: [RADIATOR] more memory leakage?

> On 27 Sep 2016, at 11:32, Heikki Vatiainen <hvn at 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…

radiator mailing list
radiator at open.com.au

More information about the radiator mailing list