[nsd-users] Larger memory footprint with direct-rdata-storage in NSD 4.14.0
Willem Toorop
willem at nlnetlabs.nl
Sat Dec 20 10:34:13 UTC 2025
Hi Saj,
Another status update ;-).
I worked on a remedy minimizing memory fragmentation for zones with
RRsets with many RRs (like DNS-SD zones). You can find it on this
branch:
https://github.com/NLnetLabs/nsd/tree/devel/reduce-fragmentation-with-many-RR-RRsets
, for which I made this PR: https://github.com/NLnetLabs/nsd/pull/472
Do you think you can find the type to try it out? With me, and my
worse-case test zone, the result was rather spectacular.
Cheers,
-- Willem
Op 19-12-2025 om 14:02 schreef Willem Toorop:
>
> Hi Saj,
>
> Just a quick update on the issue. I can reproduce.
>
> The issue is in our region-allocator. Memory recycling (which is
> happening when resizing RRsets when adding new RRs to them) is not
> performing too well when there are a relatively few, but uniquely
> large RRsets, as in RRsets with many RRs. NSD before 4.14.0 already
> didn't do too well under these circumstances, but our new release can
> do worse. So it is the combination of RRsets with a uniquely large
> number of RRs; that is uniquely large among all the zones served in a
> NSD instance.
>
> I do think I can remedy this, but there is no quick and easy fix.
>
> I'll keep you posted.
>
> -- Willem
>
> Op 17-12-2025 om 10:45 schreef Willem Toorop:
>>
>> Hi Saj,
>>
>> Thanks for looking into your findings and reporting!
>>
>> I have been testing the new RDATA storage approach with these
>> zones: .lol, .nl, .se, .net, .org and .com, which had with your
>> configure options (--enable-packed and --disable-radix-tree) compared
>> to NSD 4.13.0 compiled with the same options, the following reductions:
>>
>> * .lol: 29.3%
>> * .nl: 26.6%
>> * .se: 23.7%
>> * .net: 6.6%
>> * .org: 6.5%
>> * .com: 6.1%.
>>
>> But none of these zones have PTR records, so I am afraid I missed
>> this! I will look into this now and report back.
>>
>> Thanks again for reporting. I was about to post a blog post about my
>> testing results, but will postpone that until we've figured out what
>> is going on and possibly how to remedy it. You saved me from posting
>> a "all good news" story, which clearly needs to be nuanced.
>>
>> Regards,
>>
>> -- Willem
>>
>> Op 16-12-2025 om 15:11 schreef Saj Goonatilleke via nsd-users:
>>> Hello,
>>>
>>> We recently updated from NSD 4.13.0 to 4.14.0.
>>>
>>>> Refactor RDATA storage to reduce memory footprint
>>> https://github.com/NLnetLabs/nsd/pull/444
>>>
>>>> The amount of reduction depends on the zone contents.
>>> We observed a reduction across our smaller zones and nameservers, however we also observed the opposite: the nameservers serving our largest zones now consume more memory on NSD 4.14.0. Is this to be expected in some cases?
>>>
>>> The absolute figures here are trivial and are of no practical concern to us. We are not a registry, and so even our largest zones are tiny in comparison to some of your other users. :) I nevertheless wondered whether this behaviour was expected. If unexpected, and if the adverse outcome is liable to scale on some very large zones, maybe this report would be of interest to you.
>>>
>>> Unfortunately, I am unable to share our zone data for it includes confidential information that is not served on public networks, though I am happy to share what information I can. I will focus on one zone that was observed to consume more memory on NSD 4.14.0.
>>>
>>> nsd_size_db_in_mem_bytes (size.db.mem) went from ~6.49 Mi on NSD 4.13.0 to ~8.80 Mi on NSD 4.14.0. There are about 9K RRs in the zone. Our zones are specifically designed to serve RFC 6763 DNS-SD data (and nothing else). We never load more than one zone into each NSD server. We build with --enable-packed and --disable-radix-tree; our complete set of configure flags can be found at the bottom of this message. The positive delta is reproducible on Linux and macOS.
>>>
>>> Here is the aggregate composition of that zone by RR type:
>>>
>>> 2626 AAAA
>>> 1871 PTR
>>> 1 SOA
>>> 2736 SRV
>>> 1871 TXT
>>> =========
>>> 9105 sum
>>>
>>> I copied the zone data to my workstation then loaded it into NSD 4.13.0 and 4.14.0.
>>>
>>> NSD 4.13.0 size.db.mem=6717192
>>> NSD 4.14.0 size.db.mem=9116758
>>>
>>> (I am using a Mac and found it easiest to test here. The numbers on my Mac are a little different from our production Linux machines, though they are close.)
>>>
>>> First, out of curiosity, I removed all TXT RRs from the zone to see whether it would make a difference. (Most TXT RDATA in our zone is empty.) No, a positive delta is still observed in this case.
>>>
>>> sans TXT RRs:
>>> NSD 4.13.0 size.db.mem=6589376
>>> NSD 4.14.0 size.db.mem=9031828
>>>
>>> Next, I removed all PTR RRs from the zone. (TXT RRs were restored here.)
>>>
>>> sans PTR RRs:
>>> NSD 4.13.0 size.db.mem=1289724
>>> NSD 4.14.0 size.db.mem=1063808
>>>
>>> We observe a negative delta only after removing all PTR RRs.
>>>
>>> Here is a small representative sample of some PTR RRs with substrings redacted.
>>>
>>> _prom-exp._tcp 30 IN PTR redacted-aaaaaaaaa-master._prom-exp._tcp
>>> _prom-exp._tcp 30 IN PTR redacted-aaaaaaaaa-replica._prom-exp._tcp
>>> _prom-exp._tcp 30 IN PTR redacted-bbbbbbbb-xyzxyz._prom-exp._tcp
>>> _prom-exp._tcp 30 IN PTR redacted-bbbbbbbb-master._prom-exp._tcp
>>> _prom-exp._tcp 30 IN PTR redacted-bbbbbbbb-master-xxxxxxxxxxx._prom-exp._tcp
>>> _prom-exp._tcp 30 IN PTR redacted-bbbbbbbb-replica._prom-exp._tcp
>>> _prom-exp._tcp 30 IN PTR redacted-bbbbbbbb-replica-xxxxxxxxxxx._prom-exp._tcp
>>> _prom-exp._tcp 30 IN PTR redacted-zzzzz-master._prom-exp._tcp
>>> _prom-exp._tcp 30 IN PTR redacted-zzzzz-replica._prom-exp._tcp
>>>
>>> There are 23 unique PTR names here. _prom-exp._tcp has 1390 PTR RRs. (This is a long story.) Three other names have PTR RR counts close to 150.
>>>
>>> I thought it would be interesting to compare this zone with another. As noted above, we observed the expected reduction in memory footprint on some zones, so there must be some difference between these zones.
>>>
>>> LHS is the zone from before that exhibited a positive delta on NSD 4.14.0
>>> | RHS is a zone that exhibited a negative delta on NSD 4.14.0 (good)
>>> | |
>>> 2626 1495 AAAA
>>> 1871 964 PTR
>>> 1 1 SOA
>>> 2736 1589 SRV
>>> 1871 964 TXT
>>> ==============
>>> 9105 5013 sum
>>>
>>> In both cases, PTR RRs make up about 19-21% of the zone, though we have almost 2x as many of them in the zone that exhibited a positive delta in memory footprint when going from NSD 4.13.0 -> 4.14.0.
>>>
>>> Here are all of our configure flags.
>>>
>>> ./configure \
>>> --with-configdir=/etc/nsd \
>>> --with-nsd_conf_file=/etc/nsd/nsd.conf \
>>> --with-pidfile= \
>>> --with-user=nsd \
>>> --with-xfrdfile=/var/lib/nsd/xfrd.state \
>>> --with-zonesdir= \
>>> --without-ssl \
>>> --disable-dnstap \
>>> --disable-largefile \
>>> --disable-nsec3 \
>>> --disable-radix-tree \
>>> --disable-ratelimit \
>>> --disable-recvmmsg \
>>> --disable-root-server \
>>> --disable-systemd \
>>> --disable-zone-stats \
>>> --enable-bind8-stats \
>>> --enable-mmap \
>>> --enable-packed
>>>
>>> Thank you for your work on nsd!
>>> _______________________________________________
>>> nsd-users mailing list
>>> nsd-users at lists.nlnetlabs.nl
>>> https://lists.nlnetlabs.nl/mailman/listinfo/nsd-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20251220/7f21b790/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Type: application/pgp-keys
Size: 7749 bytes
Desc: OpenPGP public key
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20251220/7f21b790/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20251220/7f21b790/attachment-0003.bin>
More information about the nsd-users
mailing list