Re: understanding memory issues

"W.C.A. Wijngaards" <[email protected]>
Newsgroups gmane.network.dns.nsd.general
Message-ID <[email protected]>
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.
> 
> 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.

Best regards, Wouter

> 
> Best regards, Wouter
> 
>>
>> 03:44:19 nsd[16836]: xfrd: zone xx committed "received update to serial
>> 2018063010 at 2018-06-30T03:44:19 from 2a02:850:9::5 TSIG verified with
>> key rcode0-distribution"
>> 03:45:30 nsd[16837]: rehash of zone xx. with parameters 1 0 5
>> 6a0bf229ad0c7a2a
>> 03:45:39 nsd[16837]: nsec3 xx 1 %
>> 03:46:29 nsd[16837]: zone xx. received update to serial 2018063010 at
>> 2018-06-30T03:44:19 from 2a02:850:9::5 TSIG verified with key rcode0-xxx
>> of 1717205965 bytes in 324.657 seconds
>> 03:46:29 nsd[16837]: fork failed: Cannot allocate memory
>> 03:46:32 nsd[16836]: process 16837 exited with status 256
>> 03:46:32 nsd[7188]: handle_reload_cmd: reload closed cmd channel
>> 03:46:32 nsd[7188]: Reload process 16837 failed, continuing with old
>> database
>> 03:46:32 nsd[16836]: zone xx serial 2018063009 is updated to 2018063010.
>>
>>
>> What confuses me is that since above error all following attemtps to
>> transfer and activate the new zone fails, but without any reason.
>>
>>
>> 03:51:50 nsd[16836]: xfrd: zone xx committed "received update to serial
>> 2018063011 at 2018-06-30T03:51:50 from 2a02:850:9::5 TSIG verified with
>> key rcode0-xxx"
>> 03:51:58 nsd[16836]: xfrd: zone xx: soa serial 2018063011 update failed,
>> restarting transfer (notified zone)
>> 03:56:05 nsd[16836]: xfrd: zone xx committed "received update to serial
>> 2018063011 at 2018-06-30T03:56:05 from 2a02:850:9::5 TSIG verified with
>> key rcode0-xxx"
>> 03:56:18 nsd[16836]: xfrd: zone xx: soa serial 2018063011 update failed,
>> restarting transfer (notified zone)
>>
>>
>> Any idea why NSD is not logging the cause of the "update failed"? I
>> guess it is also memory related, or does NSD just not recover from the
>> initial "Cannot allocate memory"?
>>
>> Thanks
>> Klaus
>> _______________________________________________
>> nsd-users mailing list
>> [email protected]
>> https://open.nlnetlabs.nl/mailman/listinfo/nsd-users
>>
> 
> 
> 
> 
> _______________________________________________
> nsd-users mailing list
> [email protected]
> https://open.nlnetlabs.nl/mailman/listinfo/nsd-users
>

_______________________________________________
nsd-users mailing list
[email protected]
https://open.nlnetlabs.nl/mailman/listinfo/nsd-users
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE7fqj8spObrBWga+On28cLX4EX40FAls6KAQACgkQn28cLX4E
X42arA/6A7nJUki519pfxlRYf8EyIEkLcrZJwuX97wt542LQsdklgGNjeMahANkJ
QeTC/Luan9OCnWOm/PHCsyjbAarGkTu0MFbjopjJt0CukiIsIXwwhdDTPI9emFmz
uIej0428Yy7dk9d/HUwKkYVRLn92RKvXYFyAMfx8GNQcPZmbko6H/Tb7TOD0XhTE
FZ0YV/Uf8nvncSeCYZ8NS6Z+bK1r+tET/s+Ifme0YSEFRSgd7hKYn8xpULB4W/eZ
pAdtMAblBJJN4cEMYLI9/+egIQC152hyljnd9cTeh3zZQyloSpjvvKg5JpcsKPf0
kbZNr2cYfQL5U7HRdzjzr3ae4qeyTstVePQoAgPkAbQ4MeXzKiHD5BqnXuYOuQV/
gO9wtTdCV5Gz1QXex6W69VJbSGl5cKolWbC4hUSdpVON1do2DcA62jQMs1K2eI5K
98bmxYAnlz50us5ghP1vzIOvEXoAGDj05q6iSCuLWhJyj4I0rPVnOso7yHIolfSi
Gjei6rN1Ld/8GrB/tjYHONSj/a8DwZ9h1pkT2SLk7U5UV+Q5FxUu0//xKaSlm+c0
hTWm+2ZF75j9Z8FOVkCtaVD6V8hy2w4icrOqcaTox9ZCojEVRd11ynrEatWrLaOX
lcqZzJRS0WBApISFclz7JWisWAjcl72Uc2+ewZq2+p+sT4sfPQk=
=2VZx
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.