On Sun, 30 Sep 2012, Dave McGuire wrote:
On 09/30/2012 06:08 PM, Mouse wrote:
A modern Linux or BSD distribution [...] but I've
found most will run
well with 128MB so long as swap is available (and you aren't running
BIND).
I've got machines with 256 MB of RAM running current Debian Linux
just fine. And yes, one of them is actually running BIND. For
rather small zones, admittedly.
My house nameserver is a 96M NetBSD/sparc machine, running BIND. I'm
not running huge zones like .com, but there is one that's not entirely
trivial (somewhat over two thousand records). According to top, it has
64M RAM free, and that's without even touching swap, so I'm fairly sure
96M is substantial overkill for the application.
Of course, the plural of `anecdote' is not `data'. But I do believe
that you don't need anywhere near a quarter-gig of RAM just for an OS
and BIND unless the OS is pretty severely bloated or you're serving big
zones.
Now now, this is classiccmp, you know how we hate real world experience
here.
My DNS server currently handles 319 zones, and functions as a resolver
for about thirty machines. Running BIND9 on an UltraSPARC-IIe at 500MHz
(Netra V100) with 1GB of RAM running NetBSD/sparc64 v5. No graphics or
other foolishness on this server-in-a-rack machine. It is also a build
server for a couple of software projects; when those jobs kick off it
gets a bit swappy, but it's fine otherwise.
That matches up with my real world experiences. I was explicit about the
swap requirement with smaller amounts of memory for a reason.
Running BIND9 strictly as a _caching_ nameserver (the most common
application) under Debian Linux with 128MB of ram and no swap will no
longer work. The amount of memory required by BIND9 plus the basic OS (no
X, GUI, or other such fluff) will exceed 128MB of memory use and BIND will
core dump. With more memory -or- swap available, this does not happen.
This was a very unpleasant surprise when replacing the OS image on a
substantial number of embedded devices, which also included replacing
BIND8 and BIND9. In almost all cases it was trivial to just add more
memory, which has solved the problem. BIND9 might behave better while
serving small zones and not acting as a caching nameserver, but that isn't
something I've had a reason to test. While it would have been possible to
modify BIND itself so it would be better behaved, this isn't really
practical from a software maintainability standpoint.