The server now uses talloc
a.cudbardb at freeradius.org
Wed Feb 20 00:10:05 CET 2013
On 19 Feb 2013, at 17:34, Alan DeKok <aland at DEPLOYINGRADIUS.COM> wrote:
> For most things. If you pulled recently, you may need to do:
> $ git pull --force
> There were a few commits done out of order.
> But it works. Both valgrind and the talloc memory checker report
> minimal errors. There are just a few listeners leaked on exit, which is
> partly intentional. That will be fixed once the listeners are moved to
> The changes result in about 800 lines of code removed from the server.
> That's 1%, which is small but not negligible. We expect more code to
> be removed as we migrate everything else to talloc.
> We also expect that supporting "HUP" will become easier. It may have
> issues today, but talloc makes it easier to have better support for HUP.
> I haven't done any performance tests. But the Samba people say that
> talloc is 4% slower than malloc. Our other tests show that most of the
> CPU time is spent in MD5, SSL, or in accessing external DBs. So I
> expect that there should be no performance impact here.
It also allows us to do slab allocation for requests. So instead of lots of small allocs for VPs and associated meta data, we can pre-alloc request_size + 1k. This will mean server performance is increased in some cases, especially if complex unlang policies are used.
Once the rest of the server is converted to talloc we'll also be able to definitively say whether the server leaks memory, and the naming/typing of talloc memory blocks will make tracking down the source of the leak far easier.
If you're interested radiusd -XM will output a memory report on exit. Even with the minor modifications we've made it will show if RADIUS_PACKETs, configuration data, module data and VALUE_PAIRS being leaked.
radiusd -xv will also show you the version of talloc you built with. It should be something like 2.0.*.
More information about the Freeradius-Devel