On Sep 18, 2015, at 12:17 PM, A.L.M.Buxey@lboro.ac.uk wrote:
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 ?
Checking the environment is hard to do in a portable manner. The memory change mainly affects people doing high load EAP. And the changes upcoming in 3.0.10 take memory usage back to where it was... little to nothing.
(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
I have some scripts. I'll take a look.
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?
Possibly. We'll probably release 3.1 / 3.2 in a year or so. I'd like to stop new development on 3.0, and keep changes to bug fixes. Then, the next release becomes the "experiment with new features" release. Alan DeKok.