[nsd-users] CPU and memory usage

[Wouter Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ed,

On 07/10/2014 03:53 PM, Ed Y wrote:
> Hi there,
> 
> I have an NSD 4.0.3 slave running on FreeBSD.  There are about 120 
> signed (NSEC3) domain names in the db, which is 500MB.  Whenever
> the largest zone file (89MB when signed) is transferred from the
> master, the CPU load on the box sits at around 90% for several
> hours.  During this time nsd-control zonestatus shows a different
> commit serial vs served serial, indicating that it's processing.
> If I remove all of the other zone files from nsd.conf and just
> leave that 89MB zone the zone is transferred and served in less
> than 1min.
> 
> FreeBSD (64-bit) is running as a VM with 10GB of memory, it has 2 
> processors with four cores each.
> 
> I found one past nsd-users email that indicated there was a problem
> in 4.0.3 with large zone files and that the next version allows a
> separate db to be specified for large zones??

Yes that would likely help you here.  The main effect is to reduce the
memory usage, and disk usage, I think that is what NSD is spending its
time on.  It is trying to update the nsd.db and this is (apparantly)
taking a lot of time.  Perhaps the VM has a lot of memory but the host
system does not and it starts swapping to disk?

The version under development (available in the development
repository), has a feature where you can set database: "" and it then
does not make that database.  And likely, that means when you do a
zone transfer your machine does not start swapping to disk (or
whatever other pathological problems manifest at that time).  However,
without the nsd.db is still needs to use main memory, if you are short
on that, then your OS could still go swap to disk and things become
very slow.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTv4TbAAoJEJ9vHC1+BF+NTu4QAJL2ACwf+60rOErECI0EgVPg
1Jk7I7MG6394pwnzsiXNr5m/lAJM+mAH9hCWM80EnlahwcxUfKtMXyuB3mG5v3Dk
+5GZkU5F3PhQXwRo7Sf7OMZYAguVa5fMMvTATcxTCewBFTbYvNcJn8EgCPm8C0eb
N5k5Yi3FIfqvo2l68HcxuGnmSHTLY7ptd+pbaPlHlES5QeIVDbzTVpi737koECGs
0c5pi2VafZzJsS3rwc6gM02wZciAQgklgdQqMNagkaaCtL/XCO7o3lV20hI3Qv6d
fUVwQu9FrrjCdrkgVMmnvAjDsO8c9U/X2JyOymwwNpXSYDhquUMafHyr37xR0EWR
npVInjcDBAVDij10CiDuJUGwGL6YbaSzOEc35Xu2+7ewcVTGT4/u+ZnxBnVVfLdi
nIkwa1099utGe6a92kyG8HVjY8Dbktzd7xfZBlCYAs6h8mJtQJBb/vNQX02lv5KF
7ZmUUWyMNIG+CrAN5JMzsP7b116tNeCd+EdXiFzDXxSLzSQrVFKSSSLgBmlG1Gpz
Zy+sHSayW47TeO2hURgzB75mA1pK6K+geg0I9CSGFbHYbty4avO3IzjhrKUzt7l6
OFhefWPmQ93o/DwjbKowgteW5a6wKetlRKA48TwdfxDU6kQHn0nf7VegpRfzOfv6
9vhh6TViMG/FseJpU4+x
=8NLO
-----END PGP SIGNATURE-----