[nsd-users] understanding memory issues
stu at spacehopper.org
Tue Jul 3 08:26:16 UTC 2018
On 2018/07/02 18:11, Klaus Darilion wrote:
> Hi Wouter!
> Am 02.07.2018 um 15:26 schrieb W.C.A. Wijngaards:
> > Hi Klaus,
> > On 02/07/18 15:24, W.C.A. Wijngaards wrote:
> >> Hi Klaus,
> >> On 02/07/18 15:01, Klaus Darilion wrote:
> >>> Hi!
> >>> We use NSD 4.1.6 as slave for a large zone (2G zone file). It seems
> >>> sometimes the memory is too short:
> >> NSD tries to recover from the cannot allocate memory failure by
> >> performing the update again. But I guess this also fails (for the same
> >> reason?). Linux has kernel settings on memory overcommit that allow you
> >> to bypass these limits; since NSD shares most of the memory, also after
> >> fork, and this is not the default assumption of the virtual memory
> >> overcommit heuristic. But you don't really need to set it I think,
> >> because you can save memory with database: "" and by upgrading.
> We already use database: ""
> >> With NSD 4.1.6 in use one solution is update to the latest, 4.1.22. Set
> >> database: "" in nsd.conf, that saves about half memory. Then with the
> >> version upgrade, you can save half memory again on that result, by
> >> --enable-packed at compile time and the selective nsec3 allocations.
> > Oh and I missed that in 4.1.13 introduced another 15% memory savings
> > with the --disable-radix-tree configure option. You can use that option
> > on top of the previous options. I guess that is likely to solve the
> > fork failed: cannot allocate memory error.
> Couldn't you make these features enabled with a config option.
> Rebuilding is complicated and usually I want to stick with the versions
> coming with the Linux distribution.
These build options change data structures used by the program - making
that sort of change is really not feasible in runtime config.
More information about the nsd-users