Re: NSD database memory usage
"W.C.A. Wijngaards" <[email protected]>
| Newsgroups | gmane.network.dns.nsd.general |
|---|---|
| Message-ID | <[email protected]> |
Hi Antti, On 07/02/18 13:36, Antti Ristimäki wrote: > Hi Wouter, > > ----- On 6 Feb, 2018, at 16:14, W.C.A. Wijngaards [email protected] wrote: > >> Hi Antti, >> >> On 06/02/18 15:08, Antti Ristimäki wrote: >>> Hi, >>> >>> ----- On 6 Feb, 2018, at 15:46, Anand Buddhdev [email protected] wrote: >>> >>>> On 06/02/2018 13:58, W.C.A. Wijngaards wrote: >>>> >>>>> 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. >>>> >>>> Hi Wouter, thanks for the quick fix! >>>> >>>> So Antti, which unusual RRs do you have in your zone? >>> >>> That's something I also wonder, as the zone in question contains only very usual >>> RRs, mainly delegation NS records. There are quite a lot of IDN names but that >>> should probably be business as usual. >>> >>> I will try to look at the zone contents if I find anything. Wouter, anything >>> particular in mind that I should be searching for? >> >> RRs printed in the \#length hexadecimals format cause the problem that I >> found. Regardless if the type was known to NSD, it was the text >> formatting in the parser that leaked. >> >> If the problem is still there (after using patch?) then it maybe >> possible to reproduce with (a smaller subset of) the zone? > > We rebuilt the package with the patch and unfortunately it seems that the memory usage still increases after each reload like it did before the patch. We'll try to debug this further. Found the issue and fixed it in the code repository (with offlist debug). It was NSEC3 processing and previously I fixed an NSEC signed zone. Thanks for the report, Best regards, Wouter > > Antti > _______________________________________________ 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+On28cLX4EX40FAlp8FNkACgkQn28cLX4E X43eTxAAgpwmLK6sMKinFMQu3JaXXxWSFov/E5cZMkeIk1O390bTHGYCI2zVpDpB 5bDeMIC7qHToyIrkchJx6w1y9crujQhZnxcZ90VjTSnIWbZ4foqE0gsAl+PXb9UW IELR+Kgl+x56F7gi/MF/jaC0ff72YdUVDJEUtUofPh2bEuFnhuSu3zuHR8/jdjNC EwXN2tguJt9lmYg7WZoavlXtsKYX/nzjNHGLokSN+/6ms7orju2KlKTAlReyzjBB 0pmp6B4NZ7JWYkEj8KBkvLaBEZOVIP2tXwpiZysN2DTPKA/kH1KcYYWHPK4hayMW k2oEiyl8wbCrwdfExBfxepXQad/h2iEqRwVY+FqcBnfVlhh9CoACyGqCC5ps1utz T30iLcAkM576r74RxFVSsqE6O/WpWoX7yrYEVRDfL3bbyZ1MBjkg3iOaV/I36nGM KwlLOEQ0EMEZKAtDCTjt3qzU8inQQFLTPD3ZjdrYu/HCspkC04ZHY9Np3l9ej36O 1vxDsgOsyfRtmg5IFEXr3n0vXbe62pfxKaOzvWs8Bv+aSkm+gFSMBO/GzehGrOFG mY+iGOB8a8st+iZl4ExDKqbwR91N6fljl1drvAJdEl4SpO9rS443D2eUlkL2MqcC KHbKsCQXby2qUCXQQQdtiiE4x3d/v118Zc9y5aPXKvj5rwYE+Ks= =QXb3 -----END PGP SIGNATURE-----