Re: understanding memory issues

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.