Re: NSD database memory usage

"W.C.A. Wijngaards" <[email protected]>
Newsgroups gmane.network.dns.nsd.general
Message-ID <[email protected]>
Hi Antti,

It is a memory leak, thank you for the report!  Fixed it, code is copied
below and in the code repository.  It happens when unknown RR formatted
RRs are read from zonefile.

Best regards, Wouter


Index: zparser.y
===================================================================
--- zparser.y	(revision 4813)
+++ zparser.y	(working copy)
@@ -1078,16 +1078,16 @@
 rdata_unknown:	URR sp STR sp str_sp_seq trail
     {
 	    /* $2 is the number of octets, currently ignored */
-	    $$ = zparser_conv_hex(parser->region, $5.str, $5.len);
+	    $$ = zparser_conv_hex(parser->rr_region, $5.str, $5.len);

     }
     |	URR sp STR trail
     {
-	    $$ = zparser_conv_hex(parser->region, "", 0);
+	    $$ = zparser_conv_hex(parser->rr_region, "", 0);
     }
     |	URR error NL
     {
-	    $$ = zparser_conv_hex(parser->region, "", 0);
+	    $$ = zparser_conv_hex(parser->rr_region, "", 0);
     }
     ;
 %%
Index: zonec.c
===================================================================
--- zonec.c	(revision 4813)
+++ zonec.c	(working copy)
@@ -1260,6 +1260,8 @@
 			zadd_rdata_wireformat(rdatas[i].data);
 		}
 	}
+	region_recycle(parser->region, rdatas,
+		rdata_count*sizeof(rdata_atom_type));
 }


@@ -1626,6 +1628,7 @@
 			name, domain_to_string(
 			parser->current_zone->soa_rrset->rrs[0].owner));
 	}
+	region_free_all(parser->rr_region);

 	parser_flush();
 	fclose(yyin);
@@ -1719,6 +1722,7 @@
 	/* remove origin if it was not used during the parse */
 	if(parser->origin != error_domain)
 		domain_table_deldomain(parser->db, parser->origin);
+	region_free_all(parser->rr_region);
 	zonec_desetup_string_parser();
 	parser_flush();
 	return errors;


On 06/02/18 10:54, Antti Ristimäki wrote:
> Hi Anand & list,
> 
> Actually I forgot to mention it in my first message, but we do have set the database to empty value in configuration.
> 
> For us restarting NSD every now and then is not a very big problem, as this instance is only a hidden master, but naturally a more elegant solution would be very welcome.
> 
> Antti
> 
> 
> ----- On 6 Feb, 2018, at 11:47, Anand Buddhdev [email protected] wrote:
> 
>> Hi Antti,
>>
>> This is certainly a problem, and I'm sure the developers will be happy
>> to investigate it with you.
>>
>> However, I'd like to suggest that you don't use the database mode. If
>> you set:
>>
>> database: ""
>>
>> in your nsd.conf, then nsd will load the zone from the zonefile into
>> RAM, and won't bother compiling the nsd.db file. You don't really gain
>> anything with the database file, and I've been advocating for the
>> database mode to be dropped completely in future versions of nsd.
>>
>> By the way, if you or the developers find the problem, please do let us
>> know here, because I'm also curious about it.
>>
>> Regards,
>> Anand
>>
>> On 06/02/2018 09:08, Antti Ristimäki wrote:
>>> Hello,
>>>
>>> We have an installation, where NSD (version 4.1.19) acts as a hidden master for
>>> the public DNS servers. NSD has only one large zone configured and the zone is
>>> periodically signed every 20 minutes and after each re-signing, "nsd-control
>>> reload <zone>" is given so that the NSD process reloads the new zone from the
>>> zonefile and notifies the slaves. However, we noticed that the database memory
>>> usage increases after every reload, finally resulting in memory allocation
>>> failure. We stat the memory usage by running "nsd-control stats_noreset" every
>>> minute and in the graph [1] one can see the increase in size.db.mem after each
>>> reload. We don't see similar behaviour with for example xfrd process memory
>>> usage.
>>>
>>> We have worked around the issue by restarting the NSD process periodically, but
>>> do you have any ideas about the possible root cause and a more long term
>>> solution?
>>>
>>> [1] http://nxdomain.fi/NSD_db_mem.png
>> _______________________________________________
>> 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+On28cLX4EX40FAlp5pnAACgkQn28cLX4E
X412pw/+Mi7t3HOqg3eb1GMQrk+2BN3f97t1OsYzR3eG5XTiZRdPCdHlufofWhy2
eW+PF3AQ3vP21WfNK3nKO7vd2cygel3qnvD2sVG42k7gdlW8wNgicn27x4+7Ri7a
lMLUGqdQL3VIIv2ybGoaYF+Q5Xtg0nedIY7/dxuDqNoH0AyyNcpu+v7CTW4aq6eT
1XKORgtzdlTOsQbLDz0cE2d7XTmY6JkyCbDKnfm3KIimcOCf1toaE1S4/SeCZX+k
HX14LTvBx/V6rsAoG80pP0sSl0WNmE3F8yUvJ5d7grVDuRLDiO9QspmoDNvpJ85T
tfOK4OmOT5SqFs/HJVleZcsojWrC7sAm21wcMhNe4Q3mQEoMF7lgMTclCTFCV+vX
o//Qkwyzyvco3k3FwTmC3MwKzTjdRNCsSkvZsejhes7q8EoEgHx0QkGrNt7Zs7V4
qz7RxKIZwJo9rU/OrTgZwsOLCiF7oJoK/6WKn8AeM/e1mZevAMTXmSZ29kKi5DtA
Xemb+JemHG45sHoAkaMHmLhsVraL/9fFFIYdP0vXC/5oqpaEquEO3wwjX8EAzZD3
ampjsByh261jks7vu9VeVl+XlhSdo1nQqHULAr50jOusAtA6XjY8pqsjlbvye5hM
ZTzB/AYQNK+SsR3Jw3B4yX2DU3UTqJgWqa0YukRs2YLIr9ki8FI=
=JkLz
-----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.