Memory usage in 3.0

[A.L.M.Buxey at lboro.ac.uk]

Hi,

>   We moved to per-request memory pools in 3.0.8 or so.  The benefit is that the server should spend less time doing allocations.   The down side seems to be that the server is using more memory.  A lot more memory.   In some cases, double what it used before.  So for 3.0.10 we've decreased the size of the pools, which means that the memory goes back to something reasonable.

well, define 'a lot' - if this means it cannot run on eg RaspberryPi or OpenWRT systems any more than thats an issue... perhaps
the server can check its environment and limit the pool size dynamically if the value of memory is < X   ?

>   A related problem is multi-packet EAP sessions.  A typical PEAP session can take 10-15 round trips.  Due to the possibility of packets being lost, the server caches request and responses for 5 seconds.  That makes sense for PAP.  It doesn't make sense for PEAP.

yes.....I've always thought that its simpler to have the whole thing cleaned up but, as you say, if you've had the next 
part of the conversation then why keep the previous bit...you cannt go back to it

>   The attached patch implements that checking.  The new behaviour is automatic, and can't be turned off.  I'd appreciate it if people could test the patch, and see if it (a) doesn't break the server, and (b) helps with memory pressure, and (c) doesn't impact performance too much.


(c)  would really mean a lot of heavy benchmarking with EAP testing tools rather than the wishy washy 'it feels slower' from 
a real life deployment

>   The patch is against v3.0.x from today (5333d5d179da).  I'm wary of putting the patch into 3.0, but it may be a good candidate for 3.1.

but 3.1 is development/test never to be used in production..... (isnt that 3.2 when 3.1 is 'stable/sorted' ?)  in which case it will be
a long time before things can be really seen in the live world...a bit like a couple of other proposed recent changes.  perhaps in 
3.0.x with a configure flag?  --memory-adjust or such?

alan